- Glasgow-haskell-users

FlexibleContexts and FlexibleInstances
by Niklas Broberg 11 Jun '09

11 Jun '09

Dear all, This post is partly a gripe about how poor the formal documentation for various GHC extensions is, partly a gripe about how GHC blurs the lines between syntactic and type-level issues as well as between various extensions, and partly a gripe about how the Haskell 98 report is sometimes similarly blurred where syntax is concerned (or not). All these things make the life of a poor parser implementor quite miserable at times. All in good jest of course, but with an edge of truth, especially regarding (lack of) formal documentation. The issue at hand which has caused my frustration is the FlexibleContexts [1] and FlexibleInstances [2] extensions, which lift restrictions imposed by Haskell 98 on the forms of contexts and instances that may be defined. Great extensions both of them - but what do they do, really really? The following toy program requires MultiParamTypeClasses OR FlexibleContexts in order to be accepted by GHC(i): > f :: (T a b) => a -> Int > f _ = 0 This of course assumes that we import the definition of T, we *must* have MultiParamTypeClasses enabled if we want to declare T. Both extensions thus enable classes with more than one argument to appear in contexts. Changing the program to > f :: (T a ()) => a -> Int > f _ = 0 i.e. changing the second argument to T to () instead, means we now *must* have FlexibleInstances, in order to allow the non-tyvar argument. This is nothing surprising, this is what FlexibleInstances are supposed to do. But the question is, is this a syntactic issue or a typing issue? In GHC proper this doesn't really matter much, as long as it is caught *somewhere* then all is dandy. GHC's parser lets everything pass, and it's the type checker that balks at this program. But for someone like me with *only* a parser, this is a question that needs a clear answer. Looking at the online report, the productions regarding contexts are context -> class | ( class1 , ... , classn ) (n>=0) class -> qtycls tyvar | qtycls ( tyvar atype1 ... atypen ) (n>=1) qtycls -> [ modid . ] tycls tycls -> conid tyvar -> varid Ok, so clearly the () is a syntactic extension enabled by FlexibleContexts, as it is not a tyvar nor a tyvar applied to a sequence of types. So this is something that a parser should handle. FlexibleContexts also enables similar parses of contexts in other places, for instance in class declarations, for which the Haskell 98 report says topdecl -> class [scontext =>] tycls tyvar [where cdecls] scontext -> simpleclass | ( simpleclass1 , ... , simpleclassn ) (n>=0) simpleclass -> qtycls tyvar The difference here is that the simpleclass doesn't allow the tyvar applied to a sequence of types bit. FlexibleContexts lifts that restriction too, so there should be no difference between the two kinds of contexts. So the new formal productions for flexible contexts should be something like fcontext -> fclass | ( fclass1 , ... , fclassn ) (n>=0) fclass -> qtycls type1 ... typen (n>=1) topdecl -> data [fcontext =>] simpletype = constrs [deriving] | newtype [fcontext =>] simpletype = newconstr [deriving] | class [fcontext =>] tycls tyvar [where cdecls] | instance [fcontext =>] qtycls inst [where idecls] gendecl -> vars :: [fcontext =>] type Does this seem correct? Now let's turn to FlexibleInstances, which similarly lifts restrictions, only to instance declarations instead of contexts. The Haskell 98 report says on instance declarations: topdecl -> instance [scontext =>] qtycls inst [where idecls] inst -> gtycon | ( gtycon tyvar1 ... tyvark ) (k>=0, tyvars distinct) | ( tyvar1 , ... , tyvark ) (k>=2, tyvars distinct) | [ tyvar ] | ( tyvar1 -> tyvar2 ) (tyvar1 and tyvar2 distinct) Note the re-appearance of scontext, which is the same as above. The instance head must be a type constructor, possibly applied to a number of type variables, or one of three built-in syntactic cases. This is where I consider the Haskell 98 report blurry - the fact that the tyvars must be distinct, is that truly a syntactic issue? It might be, it's certainly something that could be checked syntactically. But when you take into account that with the proper extensions, they no longer need to be distinct, at what level would we expect such a check to happen? My gut feeling is that this check for distinctness is something that a type checker might do better than a parser, though it's not clear cut by any means. But since I don't do any other kind of name resolution or checking in my parser even if it would be possible (e.g. multiple declarations of the same symbol), I would find it a bit anomalous to check this too. Turning on FlexibleInstances, we shouldn't need to follow any of the above restrictions on inst. In other words, the flexible production should simply be something like finst -> type Right? Now, FlexibleInstances *also* lifts the restriction on contexts, just like FlexibleContexts - but *only* for the contexts of instance declarations. This may seem like a reasonable thing, but it certainly gives me some headaches. It means I could not treat the contexts uniformly, but would need to have separate syntactic categories (or rather post-parse checks) that look different between instance contexts and other contexts (including class). So with FlexibleInstances on, there are *three* different kinds of contexts allowed: scontext for class declaration, fcontext for instance declarations, and context for all other uses of contexts (type signatures, data/newtype declarations). Just a small headache, since I already apparently needed two categories from Haskell 98, but still. I'm not sure I find it reasonable, that flexible instances are enabled just for instance declarations but not elsewhere, but I'm sure a lot of thought was given to that. If it was up to *me* though, I would leave the flexible contexts with FlexibleContexts entirely, which means you would have to use both flags if you wanted both in your instance declarations. Would that be a bad thing? Separation of concern seems desirable to me (and no, I'm not saying that just because it would be easier to implement in the parser)... At any rate, to make a long rant short: * Are my interpretations of the lifted restrictions by FlexibleContexts and FlexibleInstances correct? * Is it reasonable that the issue of checking that tyvars are distinct should not be considered syntactic? * Would it also be reasonable to make the separation of concern between FlexibleContexts and FlexibleInstances more clean? Thanks for reading, and please give me input! Cheers, /Niklas [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensio… [2] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio…

4 6

List comprehensions and impredicative rank-N types
by Vladimir Reshetnikov 11 Jun '09

11 Jun '09

Hi, Consider the following definitions: ----------------------------------------------------------- {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} foo :: [forall a. [a] -> [a]] foo = [reverse] bar :: [a -> b] -> a -> b bar fs = head fs ----------------------------------------------------------- According to the Haskell Report, [f | f <- foo] translates to (let ok f = [f]; ok _ = [] in concatMap ok foo), right? So, I wonder why (bar [f | f <- foo]) typechecks, but (bar (let ok f = [f]; ok _ = [] in concatMap ok foo)) and (bar foo) do not typecheck? Thanks, Vladimir

1 0

Re: [darcs-users] dropping GHC 6.6 support
by Isaac Dupree 11 Jun '09

11 Jun '09

[redirecting to ghc-users also] Matthias Kilian wrote: >> (Which as I understood would make porting a newer ghc to OpenBSD easier). > > Yes. The only alternatives would be to provide precompiled binaries > (which is ugly, imho) or to maintain several versions of ghc in the > ports tree (which is a maintainance nightmare). .hc files are ugly too; IMO about as ugly as precompiled binaries (.hc are platform specific and practically unreadable, just like binaries). At least the GHC HQ think so: currently bootstrapping-from-HC only works unregisterised (so it will be slow. Also, inherently, won't ever use GHC's NCG :-) (native code generator) ) -Isaac

1 0

6.10.4 plans
by Ian Lynagh 09 Jun '09

09 Jun '09

Hi all, Unfortunately, since the release of 6.10.3, still more problems have come to light in the 6.10 branch. We are therefore planning to do a 6.10.4 release. For 6.10.4, we will only consider fixes for serious bugs that cannot be easily worked around. So far, we plan to look into: * One of the patches in 6.10.2 introduced a problem where mkWeakForeignEnv# could segfault (already fixed) * readMutVar# is inlined/duplicated http://hackage.haskell.org/trac/ghc/ticket/3207 (already fixed, patch waiting to be merged) * "Permission denied" errors on Windows: http://hackage.haskell.org/trac/ghc/ticket/3231 http://hackage.haskell.org/trac/ghc/ticket/2924 * Some ghci tests fail with hLookAhead errors. We would like to at least understand exactly what is going on here. If you find any other bugs that you think we should look into for 6.10.4, please let us know. We don't have any plans for when to do the release yet, but we would like to be confident that we have waited long enough for any other bugs to surface, and to have time for 6.10.4 to be well-tested. Thanks Ian

3 4

is the library iconv necessary for haskeline?
by Christian Maeder 08 Jun '09

08 Jun '09

Hi, building ghc-6.10.3 under x86 solaris eventually failed with: Configuring ghc-bin-6.10.3... cabal-bin: At least the following dependencies are missing: haskeline -any gmake[3]: *** [boot.stage.2] Error 1 I think, haskeline is not build because libiconv is missing: -bash-3.00$ ./Setup configure --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT --with-compiler=/export/local1/home/maeder/haskell/ghc-6.10.3/ghc/stage1-inplace/ghc --with-hc-pkg=/export/local1/home/maeder/haskell/ghc-6.10.3/utils/ghc-pkg/install-inplace/bin/ghc-pkg --libsubdir=$pkgid --with-gcc=gcc --with-ld=/usr/ccs/bin/ld --with-alex=/home/pub-bkb/bin/alex --with-happy=/home/pub-bkb/bin/happy --configure-option='--with-cc=gcc --with-hsc2hs=/export/local1/home/maeder/haskell/ghc-6.10.3/utils/hsc2hs/install-inplace/bin/hsc2hs --haddock-options=--use-contents=../index.html --use-index=../doc-index.html' --enable-library-profiling --enable-split-objs Configuring haskeline-0.6.1.5... checking whether to use -liconv... Setup: Unable to link against the iconv library. I wonder how this check for -liconv is generated. I have a file /usr/include/iconv.h but not file /usr/lib/libiconv.* Under Linux I've installed successfully http://www.haskell.org/ghc/dist/6.10.3/ghc-6.10.3-i386-unknown-linux-n.tar.… and I was able to install http://hackage.haskell.org/packages/archive/haskeline/0.6.1.6/haskeline-0.6… without libiconv! > ./Setup configure Configuring haskeline-0.6.1.6... checking whether to use -liconv... not needed. However, the mere existence of /usr/local/lib/libiconv* files causes configure to use -liconv: checking whether to use -liconv... using -liconv. I would like to avoid this (unnecessary?) dependency (without removing /usr/local/lib). (/usr/local/lib is _not_ part of LD_LIBRARY_PATH and should not be searched by gcc, but is still somehow found and used.) Are there any configure options that work? (The cabal-flag libiconv is false.) How is "checking whether to use ..." generated? Is libiconv really necessary under Solaris? Cheers Christian

2 2

Should exhaustiveness testing be on by default?
by Don Stewart 07 Jun '09

07 Jun '09

I'm not sure I'd want -Wall on by default (though being -Wall clean is very good). But exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds. http://ocaml.janestreet.com/?q=node/64 Ron's also wondering why exhaustive pattern checking isn't on ? Anyone know why it isn't the default? -- Don

12 41

Job for someone: make a VM image for GHC development
by Simon Marlow 05 Jun '09

05 Jun '09

I forget who mentioned this to me, but I think it's a great idea. Things like VirtualBox and VMWare are pretty easy to install and set up these days. It wouldn't be hard for someone to create a VM image of a Linux system with a complete GHC development environment set up and ready to go. This would have a lot of benefits: * Easy to buy into: just install VirtualBox (or whatever), download the image, register it and away you go. * Would make the barrier to entry much lower for someone who wants to make a small change, e.g. to the docs, or a library. validate and 'darcs send' would Just Work. * Would serve as an example of best-practice in setting up a GHC development environment. The hard part might be optimising the install so that we don't end up with an enormous image file. We'd probably need to find a suitably minimal Linux install, or start from an existing minimal Linux VM image. Anyone feeling keen? Cheers, Simon

3 2

Re: Job for someone: make a VM image for GHC development
by Philip K.F. Hölzenspies 05 Jun '09

05 Jun '09

Dear Simon, et al. I've looked around trying to pick up information on tiny installations of Linux. It seems most modern distributions think 200MB is a pretty barebone installation. There's a claim by someone that (s)he got a Tiny Gentoo installation into 5MB. I'll be looking into that this evening. Of the options given (installer vs. VM image), I have most faith in the VM image. From what I've seen, installers are still quite large (summed total of all downloads required) compared to a to-the-point installation. Could you be slightly more specific on what you want in the image for it to be a GHC development environment? I presume darcs is one. Also, I presume the GHC source tree isn't. Compiler-wise; do you want/need gcc on a system like this, if so, do you still want a binary GHC there? If a binary GHC is desired, do you want a bare minimum (w/o extralibs, possibly older version), the more elaborate (w/ extralibs), or the whole package (Haskell Platform)? Possibly the easiest VM image to maintain just has the minimum requirements to run emerge and a script that, on first boot of the image, emerges the haskell platform and darcs. This way, you don't need to update the VM image with updates of GHC (or updated dependencies of the GHC source tree on newer GHC versions). The upside is a very fast download of the image, but the downside is a very slow first boot of the image. Regards, Philip

2 1

[Fwd: OSX installer -- first draft]
by Duncan Coutts 04 Jun '09

04 Jun '09

OSX users, please could you try out Gregory's Haskell Platform package below and send commentary to the platform list, or file tickets in the platform trac, that'd be great. http://trac.haskell.org/haskell-platform/newticket?component=OSX%20installer The plan is that for ghc-6.12 and onwards, that this will be the primary way that end-users get their Haskell goodness on OSX, so it's important that you provide feedback now so that we can get the thing working nicely and try to make everyone happy. I'm sure Gregory would also appreciate help in working out how to make the OSX .pkg tools behave properly. Duncan -------- Forwarded Message -------- > From: Gregory Collins <greg(a)gregorycollins.net> > To: haskell-platform <haskell-platform(a)projects.haskell.org> > Subject: OSX installer -- first draft > Date: Tue, 02 Jun 2009 00:20:18 -0400 > > Hi all, > > After months of intense frustration I have something approaching a > reasonable OSX installer for the Haskell Platform. I'd appreciate it if > some OSX hackers could try it out. > > The installer can be downloaded from: > http://gregorycollins.net/static/haskell/haskell-platform-2009.2.0.1-alpha1… > > Please do me a favour and don't link there from the haskell platform > website :) > > Features/caveats: > > * it presupposes GHC-6.10.3 is installed from the binary distro. The > final release will bundle the two together in a .dmg file. > > * it installs the platform libraries and executables to > /Library/Framework/HaskellPlatform.framework, registers the > libraries with GHC, and symlinks the binaries to /usr/local/bin > > * I had to build the distro package by hand using Apple's GUI tool > because I can't figure out how to do it otherwise -- and not for > lack of trying, either, I reckon I've put 20-30 man-hours into > trying to figure it out -- thanks Apple! Similarly, for the life of > me I cannot figure out how to bundle GHC and the platform libs > together into one installer. > > * There's some haddock documentation in there but I'm not sure how > nicely it's cross-linked. > > * The code is a mess, I need to clean it up (and systematize the > process) before it's fit for inclusion into the project. > > * I've done some (very) limited testing but given how difficult the > whole project has been, I fully expect problems. > > Sorry about how long it's taken -- I'm getting married on Saturday (!) > so finding time to work on this has been difficult indeed. > > G.

2 2

space leak due to optimisations and/or newtypes
by Sebastian Fischer 04 Jun '09

04 Jun '09

Hello, I have written a Haskell program that runs much more efficiently without optimisations than with optimisations. Compiled without optimisations it finishes in about 15 seconds and runs in constant space (< 3 MB), with optimisations (both -O and -O2) it consumed all my RAM in less than 30 seconds before I killed it. The program contains four occurrences of the identity function 'id'. All of them are superflous from a declarative point of view. If I remove any of them (one is enough) then the program finishes in about 10 seconds and runs in constant space (< 3 MB) with optimisations. The (attached) program is a condensed version of a program that uses newtypes. Originally, the identity functions where newtype con- and destructors. The original program consumes a lot of memory both with and without optimisations. A version where I have inlined some newtypes runs in constant space. I have used GHC 6.10.1 on Mac OS X. Is this behaviour intended, is it a known/fixed issue of GHC 6.10.1 or should I file a bug report? Cheers, Sebastian ------- {-# LANGUAGE RankNTypes #-} newtype S a = S { unS :: forall b . (a -> Int -> [b]) -> Int -> [b] } ret x = S (\c -> c x) a `bind` f = S (\c -> unS a (\x -> unS (f x) c)) zero = S (\c _ -> []) plus a b = S (\c -> id (\d -> if d==0 then [] else id (unS a c) (d-1) ++ id (unS b c) (d-1))) runS :: S a -> [a] runS a = concatMap (\d -> id (run a) d) [10000] run :: S a -> Int -> [a] run a = unS a (\x _ -> [x]) natSum :: S Int natSum = anyof [1..] `bind` \x -> anyof [1..] `bind` \y -> ret (x+y) where anyof = foldr plus zero . map ret main = print . length $ runS natSum ------- -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

3 5