Hugs-Users

Download

hugs-users@haskell.org

October 2020

1 participants
2 discussions

Re: [Hugs-users] Datatype (and Newtype) contexts: improvement
by Anthony Clayden 15 Oct '20

15 Oct '20

Thanks Sam, apologies if I'm being dumb, but I'm not seeing the relevance of 'boilerplate'. I'm not trying to implement other compilers' language extensions (as would be clear from my occasional posts on the Hugs list). If you want GHC extensions, use GHC. There's no hope of writing stock H98 or even H2010 code. The last Hugs release (2006, used in HugsMode) has extensions way beyond the H2010 standard. I'm not trying to write code that's portable between GHC/Hugs. I'm tinkering with Hugs to give it semantics that GHC doesn't support/not even with all its extensions switched on. I'm tinkering in Hugs because it seems to be achievable whereas I just have no idea how to build GHC; and I suspect that even if I figured that out, tinkering inside GHC would be orders of magnitude more complex, because I'd keep running into all sorts of type-acrobat stuff from all of GHC's extensions. And I say "more complex" even though GHC is written in Haskell, and Hugs is written in C++ and I'd never programmed in C++ before working on Hugs; and even though C++ is imperative code, not functional. Hugs mostly uses vanilla C, with the ++ providing sourcecode edit directives -- so it goes some way towards the macro-generator of 'boilerplate' anyway. Realistically for 'industrial strength' applications like Cabal, GHC is the only game in town. Cabal should be conservative and not try to use 'bleeding edge' GHC extensions, but things like MultiParam TypeClasses, FlexibleInstances are very hard to do without (Hugs supports both). What's more, I don't see how a macro-generator like 'boilerplate' is going to help. It's not like you can macro-'translate' code using MPTCs back to H98. AntC On Thu, 15 Oct 2020 at 02:48, Sam Halliday <sam.halliday(a)gmail.com> wrote: > > Sorry, I should have started a fresh email instead of responding to the > mailing list. > > I just meant generally this might be of interest to you. The ability to > generate the code that many language extensions are generating, > therefore no need to add support in hugs. Making it easier for people to > write portable stock Haskell98 code. Maybe even things like Cabal could > be rewritten to use less extensions. > > Anthony Clayden wrote: > > Hi Sam, > > > > I'm not seeing what relevance `boilerplate` has to anything I wrote. > > > > The compiler is generating the type for the constructors within a > datatype > > (whether or not the decl gives a context). > > > > On Wed, 14 Oct 2020 at 18:55, Sam Halliday <sam.halliday(a)gmail.com> > wrote: > > > >> > >> Hi Anthony, > >> > >> Did you see this? > >> > >> http://hackage.haskell.org/package/boilerplate > >> > >> > >> > > -- > Best regards, > Sam >

1 0

Datatype (and Newtype) contexts: improvement
by Anthony Clayden 14 Oct '20

14 Oct '20

(For some background to my thinking see here https://mail.haskell.org/pipermail/haskell-cafe/2020-September/132714.html ) There's a part of the spec for DatatypeContexts that's been there since the beginning (1991), but doesn't seem right to me. The effect of the 1999 'clarification' to the spec makes it seem even less right. >From the 1991 memo "each constructor gets a context which is a subset of that given in the @data@ decl, containing all the constraints on the free type variables of the constructor signature, and no others." So we get (example from the 1998 Language Report) data Eq a => Set a = NilSet | ConsSet a (Set a) ===> NilSet :: forall a. Set a ===> ConsSet :: forall a. Eq a => a -> Set a Well, in the type signature for NilSet, `a` _is_ free, why can't it get the constraint? It's easy enough to give a signature with constraint for some appearance of `NilSet` -- except in the one place I desperately want one, that is in patterns. I can define nilSet = NilSet :: Eq a => Set a and use that on rhs of function definitions, etc. The compiler doesn't seem to come crashing down around my ears. Whereas without the `Eq a`, you can write `NilSet :: Set (Int -> Int)` without complaint to produce an unusable value -- something that will cause complaints every other place you try to consume it or Cons to it. Compare emptyS1 NilSet = True -- inferred :: Set a -> Bool emptyS1 _ = False emptyS2 (ConsSet _ _) = False -- inferred :: Eq a => Set a -> Bool emptyS2 _ = True Those two definitions are morally equivalent, but get different types. Note that prior to the 1999 'clarification' GHC would have given them both the same signature without the `Eq a`. The brains trust in 1999 was firmly of the mind the constraint should be exposed everywhere. If they'd been asked about that type for NilSet and how it didn't expose the constraint, I wonder what they'd say? Anyhoo, this note is to say it seems easy enough to modify Hugs to give the full set of constraints for every data constructor (and consequently get those exposed, so the two definitions form `emptyS` above get the same type, with the `Eq a`). Would the concern in the 1991 memo still apply in 1999, or 2006 when Hugs development ceased? "I was persuaded ... by John's comments, and by the fact that many more cases of ambiguity are likely to arise otherwise." John Hughes(?) Anyway I can see no comments on the forum. Would the ambiguities be any worse than those for Numeric Literals being `Num a => a`? Or does the defaulting mechanism rescue those? AntC

1 0