To keep the Hugs community in the loop ... Now that I have a compilable compiler, I'm picking some low-hanging fruit with syntax sugar. * I've taught Trex to support field labels starting upper-case, because, well for me they're more like constructors than variables. Unlike H98, Trex doesn't generate field accessor functions. You get #label -- or rather #Label for that. * I've always wanted records to use syntax with braces { X = 1, Y = 2 } , because, well they're a set of name-value pairs, not a mathematician's sequenced tuple. Indeed the original Gaster & Jones 1996 paper used braces. * A slight compromise: the syntax just above is ambiguous with H98, so you must put a | at the end { X = 1, Y = 2 |}. yacc inserts a `emptyRec` in the end. * And I have a format for building or updating records that uses straight { } rather than suffixing it. Might as well propose it for GHC https://github.com/ghc-proposals/ghc-proposals/issues/328. So H98 syntax, my better syntax and Trex with { ... } are co-existing. * I've added a form of NamedFieldPuns for Trex -- in both expressions and patterns: foo { X = | r } = { Y = ##X, X = | r } Heh heh punning on upper-case field labels gives an upper-case variable name. ##X goes grab the pseudo-variable. * And that's all achieved with yacc (and a bit of lexing). I haven't touched the main compiler code, which gives me good confidence I didn't stuff something up. I'm now looking at stealing some syntax from the Habit language. And syntax for FunDeps more in line with the original Mark Jones 2000 paper. Because in class C a b c | a b -> c where ... `a b` does not mean `a` applied to `b`. Also that arrow is misleading: there's not a function, but a mechanism for unification/type improvement, which is chiefly aimed at improving `c`, but might also improve `{a, b}` at some usage sites. (The original paper used `~>`, in which the tilde nicely echoes GHC's so called 'type equality constraint' -- again that's a two-way unification mechanism, not merely a type-level test.) AntC