<div dir="ltr"><div dir="ltr"><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">type.c routine typeFreshPat(l,p)    /* find type of pattern, assigning  fresh type variables to each var */</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">This sets tcMode = NEW_PATTERN  /* type-checking Mode */</font></div><div><font face="arial, sans-serif">then recurses on typeExpr(l,p) -- so tcMode is in effect an additional parameter</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Mod'ing this behaviour is giving some interesting semantics -- I'll discuss on Hugs Users list.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><font face="arial, sans-serif"><br></font><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><font face="arial, sans-serif">On Tue, 5 Oct 2021 at 13:36, Anthony Clayden <<a href="mailto:anthony.d.clayden@gmail.com">anthony.d.clayden@gmail.com</a>> wrote:<br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><font face="arial, sans-serif"><br></font></div><font face="arial, sans-serif">From this discussion 'Contexts on datatype declarations'</font><div><font face="arial, sans-serif"><a href="http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/haskell-1990-2000/threads.html#04062" target="_blank">http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/haskell-1990-2000/threads.html#04062</a><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">It looks like (at least at the time) GHC had separate functions for matching vs building using a constructor. ...</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">What I can't find is where Hugs infers the type for a data constructor appearing in matching position.<br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Any hints?  Thanks in advance</font></div><div><br></div></div>
</blockquote></div></div>