fun with yacc, and with Trex

--===============5937475824696986223==
Content-Type: multipart/alternative; boundary="0000000000007e612205a4a94221"

--0000000000007e612205a4a94221
Content-Type: text/plain; charset="UTF-8"

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

--0000000000007e612205a4a94221
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">To keep the Hugs community in the loop ... Now that I hav=
e a compilable compiler, I&#39;m picking some low-hanging fruit with syntax=
 sugar.</div><div dir=3D"auto"><br></div><div dir=3D"auto">* I&#39;ve taugh=
t Trex to support field labels starting upper-case, because,</div><div dir=
=3D"auto">=C2=A0 =C2=A0well for me they&#39;re more like constructors than =
variables.</div><div dir=3D"auto">=C2=A0 =C2=A0Unlike H98, Trex doesn&#39;t=
 generate field accessor functions. You get #label -- or rather #Label for =
that.</div><div dir=3D"auto"><br></div><div dir=3D"auto">* I&#39;ve always =
wanted records to use syntax with braces { X =3D 1, Y =3D 2 } , because,</d=
iv><div dir=3D"auto">=C2=A0 =C2=A0well they&#39;re a set of name-value pair=
s, not a mathematician&#39;s sequenced tuple.</div><div dir=3D"auto">=C2=A0=
 =C2=A0Indeed the original Gaster &amp; Jones 1996 paper used braces.</div>=
<div dir=3D"auto">* A slight compromise: the syntax just above is ambiguous=
 with H98,</div><div dir=3D"auto">=C2=A0 =C2=A0so you must put a | at the e=
nd { X =3D 1, Y =3D 2 |}. yacc inserts a `emptyRec` in the end.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">* And I have a format for building =
or updating records that uses straight { =C2=A0} rather than suffixing it.<=
/div><div dir=3D"auto">=C2=A0 =C2=A0Might as well propose it for GHC <a hre=
f=3D"https://github.com/ghc-proposals/ghc-proposals/issues/328">https://git=
hub.com/ghc-proposals/ghc-proposals/issues/328</a>.</div><div dir=3D"auto">=
=C2=A0 =C2=A0So H98 syntax, my better syntax and Trex with { ... } are co-e=
xisting.</div><div dir=3D"auto"><br></div><div dir=3D"auto">* I&#39;ve adde=
d a form of NamedFieldPuns for Trex -- in both expressions and patterns:</d=
iv><div dir=3D"auto">=C2=A0 =C2=A0foo { X =3D | r } =3D { Y =3D ##X, X =3D =
| r }</div><div dir=3D"auto">=C2=A0 =C2=A0Heh heh punning on upper-case fie=
ld labels gives an upper-case variable name.</div><div dir=3D"auto">=C2=A0 =
=C2=A0##X goes grab the pseudo-variable.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">* And that&#39;s all achieved with yacc (and a bit of lexi=
ng).</div><div dir=3D"auto">=C2=A0 =C2=A0I haven&#39;t touched the main com=
piler code, which gives me good confidence I didn&#39;t stuff something up.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">I&#39;m now looking at stealing some syntax from the Habit language. A=
nd syntax for FunDeps more in line with the original Mark Jones 2000 paper.=
 Because in</div><div dir=3D"auto"><br></div><div dir=3D"auto">=C2=A0 =C2=
=A0 class C a b c =C2=A0| a b -&gt; c =C2=A0where ...</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">`a b` does not mean `a` applied to `b`. Also =
that arrow is misleading: there&#39;s not a function, but a mechanism for u=
nification/type improvement, which is chiefly aimed at improving `c`, but m=
ight also improve `{a, b}` at some usage sites. (The original paper used `~=
&gt;`, in which the tilde nicely echoes GHC&#39;s so called &#39;type equal=
ity constraint&#39; -- again that&#39;s a two-way unification mechanism, no=
t merely a type-level test.)</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">AntC</div>

--0000000000007e612205a4a94221--

--===============5937475824696986223==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSHVncy1Vc2Vy
cyBtYWlsaW5nIGxpc3QKSHVncy1Vc2Vyc0BoYXNrZWxsLm9yZwpodHRwOi8vbWFpbC5oYXNrZWxs
Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vaHVncy11c2Vycwo=

--===============5937475824696986223==--