Re: Datatype Constructors: selector/matcher vs builder 'function'

--===============4537244831612635913==
Content-Type: multipart/alternative; boundary="000000000000f14a2505ce0cdc5d"

--000000000000f14a2505ce0cdc5d
Content-Type: text/plain; charset="UTF-8"

Hehe thank you (again) to the authors of Hugs. The answer seems to be in
exactly one place -- it just took a long time to make sure there weren't
other places interfering.

type.c routine typeFreshPat(l,p)    /* find type of pattern, assigning
 fresh type variables to each var */

This sets tcMode = NEW_PATTERN  /* type-checking Mode */
then recurses on typeExpr(l,p) -- so tcMode is in effect an additional
parameter

typeExpr( ) returns `p` with suitable bindings; but also returns the
induced context in global var `preds` -- updated as a side-effect by
calling a slather of worker routines -- chiefly in the #include'd preds.c.

If I save `preds` before recursing on typeExpr(l,p); and restore upon
return; I get no context induced for a datatype constructor appearing in
pattern position. The datatype context _is_ still inferred for the
constructor appearing in an expression, so the constraints still apply for
building.

I did break something, though: numeric patterns -- that is, literals --
aren't getting recognised, so are giving pattern match fails. The Language
Report 3.17.2, point 7 says matching to numeric literals should succeed if
`v == k`; that still works if I move the `==` test into a guard. It works
as a pattern ok for Char or String literals, so I guess I've broken how
Hugs translates the numeric literals to the `fromInteger` etc equality test.

Mod'ing this behaviour is giving some interesting semantics -- I'll discuss
on Hugs Users list.



On Tue, 5 Oct 2021 at 13:36, Anthony Clayden <[email protected]>
wrote:

>
> From this discussion 'Contexts on datatype declarations'
>
> http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/haskell-1990-2000/threads.html#04062
>
> It looks like (at least at the time) GHC had separate functions for
> matching vs building using a constructor. ...
>
> What I can't find is where Hugs infers the type for a data constructor
> appearing in matching position.
>
> Any hints?  Thanks in advance
>
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><font face=3D"arial, sans-serif"><br></fo=
nt></div><div><font face=3D"arial, sans-serif">Hehe thank you (again) to th=
e authors of Hugs. The answer seems to be in exactly one place -- it just t=
ook a long time to make sure there weren&#39;t other places interfering.</f=
ont></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font=
 face=3D"arial, sans-serif">type.c routine=C2=A0typeFreshPat(l,p) =C2=A0 =
=C2=A0/* find type of pattern, assigning =C2=A0fresh type variables to each=
 var */</font></div><div><font face=3D"arial, sans-serif"><br></font></div>=
<div><font face=3D"arial, sans-serif">This sets tcMode =3D NEW_PATTERN=C2=
=A0 /* type-checking Mode */</font></div><div><font face=3D"arial, sans-ser=
if">then recurses on typeExpr(l,p) -- so tcMode is in effect an additional =
parameter</font></div><div><font face=3D"arial, sans-serif"><br></font></di=
v><div><font face=3D"arial, sans-serif">typeExpr( ) returns `p` with suitab=
le bindings; but also returns the induced context=C2=A0in global var `preds=
` -- updated as a side-effect by calling a slather of worker routines -- ch=
iefly in the #include&#39;d preds.c.</font></div><div><font face=3D"arial, =
sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">If I sav=
e `preds` before recursing on typeExpr(l,p); and restore upon return; I get=
 no context induced for a datatype constructor=C2=A0appearing in pattern po=
sition. The datatype context _is_ still inferred for the constructor appear=
ing in an expression, so the constraints still apply for building.</font></=
div><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=
=3D"arial, sans-serif">I did break something, though: numeric patterns -- t=
hat is, literals -- aren&#39;t getting recognised, so are giving pattern ma=
tch fails. The Language Report 3.17.2, point 7 says matching to numeric lit=
erals should succeed if `v =3D=3D k`; that still works if I move the `=3D=
=3D` test into a guard. It works as a pattern ok for Char or String literal=
s, so I guess I&#39;ve broken how Hugs translates the numeric literals to t=
he `fromInteger` etc equality test.</font></div><div><font face=3D"arial, s=
ans-serif"><br></font></div><div><font face=3D"arial, sans-serif">Mod&#39;i=
ng this behaviour is giving some interesting semantics -- I&#39;ll discuss =
on Hugs Users list.</font></div><div><font face=3D"arial, sans-serif"><br><=
/font></div><div><font face=3D"arial, sans-serif"><br></font></div><font fa=
ce=3D"arial, sans-serif"><br></font><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr"><font face=3D"arial, sans-serif">On Tue, 5 Oct 20=
21 at 13:36, Anthony Clayden &lt;<a href=3D"mailto:anthony.d.clayden@gmail.=
com">[email protected]</a>&gt; wrote:<br></font></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"=
arial, sans-serif"><br></font></div><font face=3D"arial, sans-serif">From t=
his discussion &#39;Contexts on datatype declarations&#39;</font><div><font=
 face=3D"arial, sans-serif"><a href=3D"http://web.archive.org/web/201512081=
75102/http://code.haskell.org/~dons/haskell-1990-2000/threads.html#04062" t=
arget=3D"_blank">http://web.archive.org/web/20151208175102/http://code.hask=
ell.org/~dons/haskell-1990-2000/threads.html#04062</a><br></font></div><div=
><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial=
, sans-serif">It looks like (at least at the time) GHC had separate functio=
ns for matching vs building using a constructor. ...</font></div><div><font=
 face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans=
-serif">What I can&#39;t find is where Hugs infers the type for a data cons=
tructor appearing in matching position.<br></font></div><div><font face=3D"=
arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">A=
ny hints?=C2=A0 Thanks in advance</font></div><div><br></div></div>
</blockquote></div></div>

--000000000000f14a2505ce0cdc5d--

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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSHVncy1CdWdz
IG1haWxpbmcgbGlzdApIdWdzLUJ1Z3NAaGFza2VsbC5vcmcKaHR0cDovL21haWwuaGFza2VsbC5v
cmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL2h1Z3MtYnVncw==

--===============4537244831612635913==--