# Lambda the Ultimate Programming languages news, articles and discussion This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Platonic C# - Managing Referential Transparency through Unique Types DevFeed: [Platonic C# - Managing Referential Transparency through Unique Types]() Original publisher: [Read original article]() Published: 2023-03-04T20:11:56Z Content type: opinion Language: en Sources: [Lambda the Ultimate]() Topics: [C#](), [Data structures](), [context]() Tags: [c-sharp](), [context](), [data-structures](), [immutability](), [object-functional]() ### AI overview The article proposes Platonic C# as a set of rules intended to enforce referential transparency by defaulting to immutable data structures and requiring unique instances of mutable types. ### Source excerpt The idea of Platonic C# is to enforce referential transparency within the context of C#, by enforcing a set of rules around defaulting to immutability of data structures and requiring uniqueness of instances of mutable types. ## Computer History Museum releases PostScript source DevFeed: [Computer History Museum releases PostScript source]() Original publisher: [Read original article]() Published: 2022-12-13T00:15:19Z Content type: release Language: en Sources: [Lambda the Ultimate]() Topics: [releases](), [Code](), [context]() Tags: [adobe](), [code](), [computer](), [history](), [releases](), [source](), [technology]() ### AI overview The Computer History Museum, in conjunction with Adobe, has publicly released the PostScript source code for the first time. The article provides historical context about PostScript, including its impact on literacy, source-code trade secrets, engineering teams, and geometry. ### Source excerpt The Computer History Museum, in conjunction with Adobe, has released the PostScript source code. Here is the release, with some helpful historical context and several photos: The story of PostScript has many different facets. It is a story about profound changes in human literacy as well as a story of trade secrets within source code. It is a story about the importance of teams, and of geometry. And it is a story of the motivations and educations of engineer-entrepreneurs. The Computer History Museum is excited to publicly release, for the first time, the source code for the breakthrough printing technology, PostScript. We thank Adobe, Inc. for their permission and support, and John Warnock for championing this release. ## The Verse Calculus: a Core Calculus for Functional Logic Programming DevFeed: [The Verse Calculus: a Core Calculus for Functional Logic Programming]() Original publisher: [Read original article]() Published: 2022-12-12T16:23:17Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Programming](), [Math and Logic]() Tags: [draft](), [functional](), [lambda-calculus](), [languages](), [logic](), [paper](), [programming](), [rewrite](), [semantics]() ### AI overview The draft paper introduces the Verse calculus (VC), a core calculus for functional logic programming. Its main contribution is a small-step rewrite semantics that enables reasoning about VC programs through successive rewrites, as with lambda calculus. The authors note that the design is still a work in progress and that the current rewrite rules may not be confluent. ### Source excerpt The Verse Calculus: a Core Calculus for Functional Logic Programming https://simon.peytonjones.org/assets/pdfs/verse-conf.pdf LENNART AUGUSTSSON, Epic Games, Sweden JOACHIM BREITNER KOEN CLAESSEN, Epic Games, Sweden RANJIT JHALA, Epic Games, USA SIMON PEYTON JONES, Epic Games, United Kingdom OLIN SHIVERS, Epic Games, USA/li> TIM SWEENEY, Epic Games, USA Functional logic languages have a rich literature, but it is tricky to give them a satisfying semantics. In this paper we describe the Verse calculus, VC, a new core calculus for functional logical programming. Our main contribution is to equip VC with a small-step rewrite semantics, so that we can reason about a VC program in the same way as one does with lambda calculus; that is, by applying successive rewrites to it. This draft paper describes our current thinking about Verse. It is very much a work in progress, not a finished product. The broad outlines of the design are stable. However, the details of the rewrite rules may well change; we think that the current rules are not confluent, in tiresome ways. (If you are knowledgeable about confluence proofs, please talk to us!)We are eager to enagage in a dialogue with the community. Please do write to us. ## LtU is now running in a new, more stable environment DevFeed: [LtU is now running in a new, more stable environment]() Original publisher: [Read original article]() Published: 2022-08-31T06:37:45Z Content type: news Language: en Sources: [Lambda the Ultimate]() Topics: [Software](), [coding]() Tags: [admin](), [downtime](), [infrastructure](), [running](), [software]() ### AI overview LtU experienced an extended period of downtime because its software infrastructure had become outdated and difficult to maintain. It has since migrated to a new environment expected to improve stability. ### Source excerpt LtU has experienced a long period of downtime recently. Its software infrastructure was outdated enough that it became difficult to maintain when problems arose. It has now been migrated to a brand new environment. It should be much more stable from now on. ## Graydon Hoare: 21 compilers and 3 orders of magnitude in 60 minutes DevFeed: [Graydon Hoare: 21 compilers and 3 orders of magnitude in 60 minutes]() Original publisher: [Read original article]() Published: 2022-02-27T14:47:26Z Content type: opinion Language: en Sources: [Lambda the Ultimate]() Topics: [Compiler](), [Code](), [Lisp](), [Machine learning]() Tags: [bytecode](), [compiler](), [compilers](), [efficiency](), [implementation](), [lisp](), [ml](), [pdf](), [presentation](), [talk](), [theory]() ### AI overview The article discusses Graydon Hoare's 2019 undergraduate talk about compiler design, summarizing different approaches ranging from large traditional compilers to variants using selective optimization, compiler-friendly languages, theory-driven tools, intermediate representations, interpretation, partial evaluation, or hand-written implementations. ### Source excerpt In 2019, Graydon Hoare gave a talk to undergraduates (PDF of slides) trying to communicate a sense of what compilers looked like from the perspective of people who did it for a living. I've been aware of this talk for over a year and meant to submit a story here, but was overcome by the sheer number of excellent observations. I'll just summarise the groups he uses: The giants: by which he means the big compilers that are built the old-fashioned way that throw massive resources at attaining efficiency The variants, which use tricks to avoid being so massive: Fewer optimisations: be traditional, but be selective and only the optimisations that really pay off Use compiler-friendly languages, by which he is really taking about languages that are good for implementing compilers, like Lisp and ML Theory-driven meta-languages, esp. how something like yacc allows a traditional Dragon-book style compiler to be written more easily Base compiler on a carefully designed IR that is either easy to compile or reasonable to bytecode-interpret Exercise discretion to have the object code be a mix of compiled and interpreted Use sophisticated partial evaluation Forget tradition and implement everything directly by hand I really recommend spending time working through these slides. While much of the material I was familiar with, enough was new, and I really appreciated the well-made points, shout-outs to projects that deserve more visibility, such as Nanopass compilers and CakeML, and the presentation of the Futamura projections, a famously tricky concept, at the undergraduate level. ## Latent Effects for Reusable Language Components DevFeed: [Latent Effects for Reusable Language Components]() Original publisher: [Read original article]() Published: 2021-10-14T14:02:48Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Haskell](), [Programming](), [Development](), [implementation]() Tags: [abstraction](), [deferred](), [effects](), [examples](), [functional](), [haskell](), [modular](), [monad](), [programming-languages](), [semantics](), [theory]() ### AI overview The article discusses latent effects, a generic class of control-flow mechanisms for modular language definitions. It describes how function abstractions, lazy computations, and MetaML-like staging can be expressed and combined, with a full Haskell implementation and examples. ### Source excerpt Latent Effects for Reusable Language Components, by Birthe van den Berg, Tom Schrijvers, Casper Bach Poulsen, Nicolas Wu: The development of programming languages can be quite complicated and costly. Hence, much effort has been devoted to the modular definition of language features that can be reused in various combinations to define new languages and experiment with their semantics. A notable outcome of these efforts is the algebra-based "datatypes "a la carte" (DTC) approach. When combined with algebraic effects, DTC can model a wide range of common language features. Unfortunately, the current state of the art does not cover modular definitions of advanced control-flow mechanisms that defer execution to an appropriate point, such as call-by-name and call-by-need evaluation, as well as (multi-)staging. This paper defines latent effects, a generic class of such control-flow mechanisms. We demonstrate how function abstractions, lazy computations and a MetaML-like staging can all be expressed in a modular fashion using latent effects, and how they can be combined in various ways to obtain complex semantics. We provide a full Haskell implementation of our effects and handlers with a range of examples. Looks like a nice generalization of the basic approach taken by algebraic effects to more subtle contexts. Algebraic effects have been discussed here on LtU many times. I think this description from section 2.3 is a pretty good overview of their approach: LE&H is based on a different, more sophisticated structure than AE&H's free monad. This structure supports non-atomic operations (e.g., function abstraction, thunking, quoting) that contain or delimit computations whose execution may be deferred. Also, the layered handling is different. The idea is still the same, to replace bit by bit the structure of the tree by its meaning. Yet, while AE&H grows the meaning around the shrinking tree, LE&H grows little "pockets of meaning" around the individual nodes remaining in the ## Introducing PathQuery, Google's Graph Query Language DevFeed: [Introducing PathQuery, Google's Graph Query Language]() Original publisher: [Read original article]() Published: 2021-06-30T13:23:37Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Graphs](), [Query (disambiguation)](), [Google](), [data](), [Code](), [Latency](), [Optimization](), [modules](), [Object-relational mapping]() Tags: [code](), [data](), [declarative](), [dsl](), [google](), [graph](), [latency](), [mapping](), [module](), [optimization](), [semantics]() ### AI overview The article introduces PathQuery, a graph query language developed at Google to handle large query and data volumes and support its internal developer community. It describes declarative graph-traversal syntax, a foundation in a custom relational algebra variant, optimization opportunities, and a module and compilation system for reuse across projects. ### Source excerpt Introducing PathQuery, Google's Graph Query Language We introduce PathQuery, a graph query language developed to scale with Google's query and data volumes as well as its internal developer community. PathQuery supports flexible and declarative semantics. We have found that this enables query developers to think in a naturally "graphy" design space and to avoid the additional cognitive effort of coordinating numerous joins and subqueries often required to express an equivalent query in a relational space. Despite its traversal-oriented syntactic style, PathQuery has a foundation on a custom variant of relational algebra -- the exposition of which we presently defer -- allowing for the application of both common and novel optimizations. We believe that PathQuery has withstood a "test of time" at Google, under both large scale and low latency requirements. We thus share herein a language design that admits a rigorous declarative semantics, has scaled well in practice, and provides a natural syntax for graph traversals while also admitting complex graph patterns. Things that are somewhat interesting to me, from an engineering standpoint: 1. PathQuery has a module/compilation system, enabling re-use of PathQuery modules across projects. (Someone had mentioned that Google has around 40,000 PathQuery modules already, internally...) 2. PathQuery supports native functions so that some query pieces can be evaluated procedurally (peephole optimization) 3. Use of relational algebra to enable a lot of known optimizations, plus future optimizations Also, from a socio-linguistic perspective, Graph Languages are effectively the new Object-Relational Mapping layer, but they solve an interesting organizational problem of allowing multiple teams to code in different languages, without needing to re-write / re-implement entities and mapping configurations in each language. It's the Old New Thing again... ## Google announces Logica, a reusable language for data queries DevFeed: [Google announces Logica, a reusable language for data queries]() Original publisher: [Read original article]() Published: 2021-04-29T14:50:27Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Programming](), [SQL](), [Google](), [data](), [Open Source]() Tags: [fun](), [google](), [logic](), [open-source](), [programming](), [sql](), [syntax]() ### AI overview The article discusses Logica, a Datalog-like language developed internally at Google for organizing data queries into small, understandable, reusable pieces of logic. It contrasts Logica's workflow with SQL, which has limited support for packages, imports, and higher-level function composition. ### Source excerpt You can read more about it at the Google Open Source blog post, Logica: organizing your data queries, making them universally reusable and fun. They advocate for datalog-like language they developed internally at Google. The reason? Good programming is about creating small, understandable, reusable pieces of logic that can be tested, given names, and organized into packages which can later be used to construct more useful pieces of logic. SQL resists this workflow. Although you can encapsulate certain repeated computations into views and functions, the syntax and support for these can vary among implementations, the notions of packages and imports are generally nonexistent, and higher-level constructions (e.g. passing a function to a function) are impossible. ## Coq development team is open to renaming the project DevFeed: [Coq development team is open to renaming the project]() Original publisher: [Read original article]() Published: 2021-04-08T13:47:05Z Content type: release Language: en Sources: [Lambda the Ultimate]() Topics: [Coq](), [Development]() Tags: [community](), [diversity](), [gender](), [general]() ### AI overview The Coq development team says it is open to renaming Coq after community discussions about the project's name, logo, and slang meaning in English, including concerns about gender diversity and its effect on participation. ### Source excerpt From the Coq-club: The Coq development team acknowledges the recent discussions (started on the Coq-Club mailing list) around Coq's logo and name. We wish to thank everyone that participated in these discussions. Testimonies from people who experienced harassment or awkward situations, reports about students (notably women) who ended up not learning / using Coq because of its name, were all very important so that the community could fully recognize the impact of the current name and its slang meaning in English, especially with respect to gender-diversity in the Coq community. For these reasons, the Coq development team is open to a renaming. Suggestions for alternative names go here. ## LAMBDA: An Excel worksheet function for defining new functions DevFeed: [LAMBDA: An Excel worksheet function for defining new functions]() Original publisher: [Read original article]() Published: 2021-01-27T03:27:09Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Programming](), [Programming language](), [data](), [decision-making](), [Microsoft]() Tags: [data](), [decision-making](), [excel](), [fun](), [function](), [lambda](), [lambda-calculus](), [microsoft](), [programming-language]() ### AI overview The post describes LAMBDA, an Excel worksheet function that lets users define new functions. It addresses limitations of Excel's formula language, including its previous lack of user-defined functions and support for only scalar values. ### Source excerpt Post by Andy Gordon and Simon Peyton Jones on LAMBDA giving Excel users the ability to define functions. Ever since it was released in the 1980s, Microsoft Excel has changed how people organize, analyze, and visualize their data, providing a basis for decision-making for the millions of people who use it each day. It's also the world's most widely used programming language. Excel formulas are written by an order of magnitude more users than all the C, C++, C#, Java, and Python programmers in the world combined. Despite its success, considered as a programming language Excel has fundamental weaknesses. Over the years, two particular shortcomings have stood out: (1) the Excel formula language really only supported scalar values--numbers, strings, and Booleans--and (2) it didn't let users define new functions. Until now. ## Google Brain's Jax and Flax DevFeed: [Google Brain's Jax and Flax]() Original publisher: [Read original article]() Published: 2021-01-15T13:59:26Z Content type: opinion Language: en Sources: [Lambda the Ultimate]() Topics: [Artificial Intelligence](), [Deep learning](), [Google](), [Algorithms](), [NumPy](), [Python](), [Optimization]() Tags: [ai](), [algorithms](), [array](), [customization](), [deep-learning](), [google](), [implementation](), [optimization](), [python](), [scientific-programming](), [software-engineering]() ### AI overview The article introduces Google Brain's JAX and Flax alongside TensorFlow. It describes JAX as a higher-level language for specifying deep learning algorithms, combining Autograd and XLA, while Flax supports customization of existing models. It ends by asking about the future of domain-specific languages for AI. ### Source excerpt Google's AI division, Google Brain, has two main products for deep learning: TensorFlow and Jax. While TensorFlow is best known, Jax can be thought of as a higher-level language for specifying deep learning algorithms while automatically eliding code that doesn't need to run as part of the model. Jax evolved from Autograd, and is a combination of Autograd and XLA. Autograd "can automatically differentiate native Python and Numpy code. It can handle a large subset of Python's features, including loops, ifs, recursion and closures, and it can even take derivatives of derivatives of derivatives. It supports reverse-mode differentiation (a.k.a. backpropagation), which means it can efficiently take gradients of scalar-valued functions with respect to array-valued arguments, as well as forward-mode differentiation, and the two can be composed arbitrarily. The main intended application of Autograd is gradient-based optimization." Flax is then built on top of Jax, and allows for easier customization of existing models. What do you see as the future of domain specific languages for AI? ## COBOL and the Value of Maintaining Older Systems DevFeed: [COBOL and the Value of Maintaining Older Systems]() Original publisher: [Read original article]() Published: 2020-09-21T07:10:51Z Content type: opinion Language: en Sources: [Lambda the Ultimate]() Topics: [cobol](), [Programming](), [systems]() Tags: [cobol](), [critiques](), [history](), [programming-languages](), [systems]() ### AI overview The article challenges the claim that COBOL programmers disappeared because their skills became obsolete. It argues that underinvestment in people and infrastructure displaced experienced programmers, while new COBOL programmers continue to be trained. It presents older systems as valuable and discusses the importance of studying the social, political, and economic forces shaping programming languages and technological systems. ### Source excerpt Mar Hicks. Built to Last. Logic. Issue 11, "Care". It was this austerity-driven lack of investment in people--rather than the handy fiction, peddled by state governments, that programmers with obsolete skills retired--that removed COBOL programmers years before this recent crisis. The reality is that there are plenty of new COBOL programmers out there who could do the job. In fact, the majority of people in the COBOL programmers' Facebook group are twenty-five to thirty-five-years-old, and the number of people being trained to program and maintain COBOL systems globally is only growing. Many people who work with COBOL graduated in the 1990s or 2000s and have spent most of their twenty-first century careers maintaining and programming COBOL systems... In this sense, COBOL and its scapegoating show us an important aspect of high tech that few in Silicon Valley, or in government, seem to understand. Older systems have value, and constantly building new technological systems for short-term profit at the expense of existing infrastructure is not progress. In fact, it is among the most regressive paths a society can take. Recently, work on the history of technology has been becoming increasingly more sophisticated and moved beyond telling the story of impressive technology to trying to unravel the social, political, and economic forces that affected the development, deployment, and use of a wide range of technologies and technological systems. Luckily, this trend is beginning to manifest itself in studies of the history of programming languages. While not replacing the need for careful, deeply informed, studies of the internal intellectual forces affecting the development of programming languages, these studies add a sorely needed aspect to the stories we tell. ## Tackling the Awkward Squad for Reactive Programming DevFeed: [Tackling the Awkward Squad for Reactive Programming]() Original publisher: [Read original article]() Published: 2020-09-15T17:48:50Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [reactive](), [Programming](), [IO](), [Scala](), [JavaScript]() Tags: [effects](), [implementation](), [javascript](), [ltu-forum](), [programming](), [reactive](), [reactive-programming](), [scala](), [streams]() ### AI overview This paper examines how reactive programming is embedded within applications that also use imperative languages such as JavaScript or Scala. It identifies long-running computations, side effects, and coordination between imperative and reactive code as key concerns, then proposes the Actor-Reactor Model, which separates actors and reactors and composes them through data streams. The model is demonstrated in the Stella language. ### Source excerpt https://2020.ecoop.org/details/ecoop-2020-papers/19/Tackling-the-Awkward-Squad-for-Reactive-Programming-The-Actor-Reactor-Model Sam Van den Vonder, Thierry Renaux, Bjarno Oeyen, Joeri De Koster, Wolfgang De Meuter Reactive programming is a programming paradigm whereby programs are internally represented by a dependency graph, which is used to automatically (re)compute parts of a program whenever its input changes. In practice reactive programming can only be used for some parts of an application: a reactive program is usually embedded in an application that is still written in ordinary imperative languages such as JavaScript or Scala. In this paper we investigate this embedding and we distill "the awkward squad for reactive programming" as 3 concerns that are essential for real-world software development, but that do not fit within reactive programming. They are related to long lasting computations, side-effects, and the coordination between imperative and reactive code. To solve these issues we design a new programming model called the Actor-Reactor Model in which programs are split up in a number of actors and reactors. Actors and reactors enforce a strict separation of imperative and reactive code, and they can be composed via a number of composition operators that make use of data streams. We demonstrate the model via our own implementation in a language called Stella. ## The Simple Essence of Algebraic Subtyping: Principal Type Inference with Subtyping Made Easy DevFeed: [The Simple Essence of Algebraic Subtyping: Principal Type Inference with Subtyping Made Easy]() Original publisher: [Read original article]() Published: 2020-07-24T07:46:20Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Algorithm](), [Code](), [Parser](), [pretty printing]() Tags: [algorithm](), [blog-post](), [code](), [parsing](), [pretty-printing](), [type-theory]() ### AI overview The article presents Simple-sub, an alternative algorithm for algebraic subtyping and principal type inference. It argues that MLsub's biunification-based specification can be understood without bisubstitution, polar types, and advanced abstract algebra, and reports that the implementation fits in under 500 lines of code. ### Source excerpt The Simple Essence of Algebraic Subtyping: Principal Type Inference with Subtyping Made Easy, Lionel Parreaux, ICFP 2020. MLsub extends traditional Hindley-Milner type inference with subtyping while preserving compact principal types, an exciting new development. However, its specification in terms of biunification is difficult to understand, relying on the new concepts of bisubstitution and polar types, and making use of advanced notions from abstract algebra. In this paper, we show that these are in fact not essential to understanding the mechanisms at play in MLsub. We propose an alternative algorithm called Simple-sub, which can be implemented efficiently in under 500 lines of code (including parsing, simplification, and pretty-printing), looks more familiar, and is easier to understand. There's also an introductory blog post and an online demo. Stephen Dolan's Algebraic Subtyping (discussion) unexpectedly provided a solution to the problem of combining type inference and subtyping, but used somewhat heavy and unusual machinery. Now Lionel Parreaux shows that the system can be implemented in a very straightforward and pleasing way. Here's to hoping that it makes it into real languages! ## Applications of Blockchain to Programming Language Theory DevFeed: [Applications of Blockchain to Programming Language Theory]() Original publisher: [Read original article]() Published: 2020-04-13T14:38:12Z Content type: opinion Language: en Sources: [Lambda the Ultimate]() Topics: [Blockchain](), [Programming](), [Programming language](), [smart contract](), [distributed-systems]() Tags: [blockchain](), [bug](), [distributed-computing](), [ethereum](), [fun](), [implementation](), [programming](), [programming-language](), [semantics](), [smart-contract](), [transactions](), [verification]() ### AI overview A forum discussion explores how blockchain could contribute to programming language theory, practice, and developer productivity. It considers mutual and common knowledge, distributed computing fabrics, third-party transactions, and the verification and security of smart contracts, including an Ethereum smart-contract logic bug. ### Source excerpt Let's talk about Blockchain. Goal is to use this forum topic to highlight its usefulness to programming language theory and practice. If you're familiar with existing research efforts, please share them here. In addition, feel free to generate ideas for how Blockchain could improve languages and developer productivity. As one tasty example: Blockchain helps to formalize thinking about mutual knowledge and common knowledge, and potentially think about sharing intergalactic computing power through vast distributed computing fabrics. If we can design contracts in such a way that maximizes the usage of mutual knowledge while minimizing common knowledge to situations where you have to "prove your collateral", third-party transactions could eliminate a lot of back office burden. But, there might be benefits in other areas of computer science from such research, as well. Some language researchers, like Mark S. Miller, have always dreamed of Agoric and the Decades-Long Quest for Secure Smart Contracts. Some may also be aware that verification of smart contracts is an important research area, because of the notorious theft of purse via logic bug in an Ethereum smart contract.