Graph rewriting semantics for functional programming languages

Abstract

Abstract. The lambda calculus forms without any q uestion *the* theoretical backbone o f f u n ctional programming languages. For the design and implementation of the lazy functional language Concurrent C l e a n w e have used a related computational model: Term Graph Rewriting Systems (TGRS's). T h is paper wraps up our main conclusions after 10 years of experience with graph rewriting semantics for functional programming languages. TGRS's are not a direct extension of the l a m bdacalculus, so one sometimes has to re-establish known theoretical results. But T G R S 's are that much closer to the world of functional programming t h at its use has been proven to be very worthwhile. In TGRS's functions h a ve names, there are constants, pattern matching and one can choose to either share expressions or copy t h e m . Graph reduction very accurately models the essential behaviour o f m ost implementations of functional languages and therefore it forms a g o o d base for reasoning about reduction properties as well as the time and space consumption of functional applications. With uniqueness typing important information can be derived for ecient i m plementation and for purely functional interfacing w i t h i m perative programs.

EditorArrow: An arrow-based model for editor-based programming

“…In order to verify the correctness of EditorArrow, we create a reference implementation of EditorArrow, called EditorArrowCore, in the pure and lazy, graph rewriting, functional programming language Clean (Eekelen et al, 1997;Plasmeijer & Eekelen, 1999, 2002) (for readers who are more familiar with the functional language Haskell (Hudak et al, 2007), we refer to Groningen et al, 2010, for a detailed overview of the differences between Clean and Haskell and how to merge the two languages). We use Clean because it comes with the interactive proof assistant Sparkle (Mol et al, 2002(Mol et al, , 2008Kesteren et al, 2004;Mol, 2009).…”