Abstract We present an empirical study on the ability of Large Language Models (LLMs) to understand code by detecting semantically equivalent and inequivalent programs, that is, whether they compute the same result given the same input or not. To probe this, we deliberately perturb the program text by introducing semantics-preserving code transformations, namely copy propagation and constant folding. Using a benchmark of 11 Python functions with both equivalent and non-equivalent variants, we evaluate seven state-of-the-art LLMs (including ChatGPT, Claude, Gemini, and Deep-Seek) under zero-shot prompting, with and without minimal context. Despite strong performance in code generation tasks, the models often fail in this deeper reasoning challenge, misclassifying 41% of equivalent cases without context and 29% with context. Although prompting can improve performance, it does not address the underlying limitations of the models. We argue that improving LLMs themselves, through targeted fine-tuning, contrastive learning on equivalent and nonequivalent implementations, or training on transformation-invariant code, will be necessary for robust semantic understanding. Meanwhile, practitioners can achieve better results by selecting stronger models, carefully engineering prom-pts, or writing code with tools that normalize low-level differences before inference.

Smart contracts have played a pivotal role in the evolution of blockchains and Decentralized Applications (DApps). As DApps continue to gain widespread adoption, multiple smart contract languages have been and are being made available to developers, each with its distinctive features, strengths, and weaknesses. In this paper, we examine the smart contract languages used in major blockchain platforms, with the goal of providing a comprehensive assessment of their main properties. Our analysis targets the programming languages rather than the underlying architecture: as a result, while we do consider the interplay between language design and blockchain model, our main focus remains on language-specific features such as usability, programming style, safety and security. To conduct our assessment, we propose an original benchmark which encompasses a wide, yet manageable, spectrum of key use cases that cut across all the smart contract languages under examination. • We give an abstract overview of smart contract platforms, discussing the impact of different design choices. • We illustrate by examples how different design choices give rise to different programming styles for smart contracts. • We consider 6 leading smart contract languages: Solidity (Ethereum), Rust (Solana), Aiken (Cardano), PyTeal (Algorand), Move (Aptos), SmartPy (Tezos). • We develop an open-source benchmark of use cases of smart contracts, implemented in all the languages in our selection. • Based on our benchmark, we evaluate smart contract languages focussing on their security, code readability, usability, and functionalities.

Most ML-like functional languages provide records and overloading as unrelated features. Records not only represent data structures, but are also used to implement dictionary passing, whereas overloading produces type constraints that are basically dictionaries subject to compiler-driven dispatching. In this paper we explore how records and overloading constraints can be converted one into the other, allowing the programmer to switch between the two at a very reasonable cost in terms of syntactic overhead. To achieve this we introduce two language constructs, namely inject and eject, performing a type-driven syntactic transformation. The former literally injects constraints into the type and produces a function adding an extra record argument. The latter does the opposite, ejecting a record argument from a function and turning fields into type constraints. The conversion is reversible and can be restricted to a subset of symbols, granting additional control to the programmer. Although what we call inject has already been proposed in literature, making it a language operator and coupling it with its reverse counterpart represent a novel design. The goal is to allow the programmer to switch from a dictionary-passing style to compiler-assisted constraint resolution, and vice versa, enabling reuse between libraries that otherwise would not interoperate.

BACKGROUND: Residue Interaction Networks (RINs) map the crystallographic description of a protein into a graph, where amino acids are represented as nodes and non-covalent bonds as edges. Determination and visualization of a protein as a RIN provides insights on the topological properties (and hence their related biological functions) of large proteins without dealing with the full complexity of the three-dimensional description, and hence it represents an invaluable tool of modern bioinformatics. RESULTS: We present RINmaker, a fast, flexible, and powerful tool for determining and visualizing RINs that include all standard non-covalent interactions. RINmaker is offered as a cross-platform and open source software that can be used either as a command-line tool or through a web application or a web API service. We benchmark its efficiency against the main alternatives and provide explicit tests to show its performance and its correctness. CONCLUSIONS: RINmaker is designed to be fully customizable, from a simple and handy support for experimental research to a sophisticated computational tool that can be embedded into a large computational pipeline. Hence, it paves the way to bridge the gap between data-driven/machine learning approaches and numerical simulations of simple, physically motivated, models.