[Hugs-users] fun with yacc, and with Trex

[Anthony Clayden]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hugs-users/attachments/20200503/9288c88e/attachment.html>