From anthony.d.clayden at gmail.com Tue Oct 5 00:36:25 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Tue, 5 Oct 2021 13:36:25 +1300 Subject: Datatype Constructors: selector/matcher vs builder 'function' Message-ID: >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. In Hugs, the type for a datatype's constructor(s) is inferred in static.c routine selectCtxt( ) called from depConstrs( ). The type for field (label) selectors is inferred in type.c routine typeSel( ). And it's easy enough to hack that to drop the preds on the selectors, as SPJ advocates in that thread. What I can't find is where Hugs infers the type for a data constructor appearing in matching position. Any hints? Thanks in advance AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Mon Oct 11 05:18:35 2021 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Mon, 11 Oct 2021 18:18:35 +1300 Subject: Datatype Constructors: selector/matcher vs builder 'function' In-Reply-To: References: Message-ID: 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 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: