June 2009 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Three patches for cabal
by Niklas Broberg 09 Nov '09

09 Nov '09

(Trying again since my previous patches were too big for the list.) While doing a survey[1] of the extensions registered with Cabal, I came across two warts in the list of constructors, and one constructor that should be deprecated. First there's the constructor called TransformListComp, which should really be named GeneralizedListComp, since the constructor should describe the extension and not the implementation scheme. Second there's the constructor NoMonoPatBinds, which actually describes the default Haskell 98 behavior, even if GHC has a different default. It's GHC's behavior that is the extension, so the constructor in cabal should really be named MonoPatBinds. Also, the PatternSignatures constructor has been deprecated in GHC and superceded by ScopedTypeVariables. The attached patches (three in one file) adds the proposed new constructors, deprecates the old ones, and adds documentation. Cheers, /Niklas

8 15

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 22 Sep '09

22 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

8 13

Proposal: Deprecate ExistentialQuantification
by Niklas Broberg 24 Jul '09

24 Jul '09

Hi all, Following the discussion on the use of 'forall' and extensions that use it [1], I would hereby like to propose that the ExistentialQuantification extension is deprecated. My rationale is as follows. With the introduction of GADTs, we now have two ways to write datatype declarations, the old simple way and the GADTs way. The GADTs way fits better syntactically with Haskell's other syntactic constructs, in all ways. The general style is (somewhat simplified) "keyword type 'where' decls", where keyword can in Haskell 98 be class or instance, but with GADTs also data. The old simple way of defining data types is the odd one out. It certainly has its uses though, in particular when defining some simple (but possibly large) enum-like datatype (like cabal's Extension type incidentally), then it obviously becomes tedious to have to restate the trivial type signature for each constructor. Using GADTs style syntax it is possible to allow constructors with existentially quantified arguments with *no additional syntax needed*. It follows nicely from the standard syntax for type signature declarations (assuming explicit foralls), e.g. the following "normal" datatype declaration data Foo = forall a . Show a => Foo a which uses ExistentialQuantification syntax, could be written as data Foo where Foo :: forall a . Show a => a -> Foo which is syntactically just a normal type signature. The upside of deprecating ExistentialQuantification is thus that we keep the syntax cleaner, and we keep the old style of datatype declarations simple (as it should be, IMO). Anything fancier can use the GADTs syntax, which anyone that uses something fancier should be acquainted with anyway. The downside is that we lose one level of granularity in the type system. GADTs enables a lot more semantic possibilities for constructors than ExistentialQuantification does, and baking the latter into the former means we have no way of specifying that we *only* want to use the capabilities of ExistentialQuantification. My own take on that is that what we have now is a wart that should be removed, and that if we think that the latter is a problem then the way to go would be to split the monolithic GADTs extension into several semantic levels. There is of course also the downside that we break existing code, but that's a standard problem with improvement through deprecation which I will pay no mind. Discussion period: 2 weeks Cheers, /Niklas [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017432.html

12 23

Proposal: ExplicitForall
by Niklas Broberg 23 Jul '09

23 Jul '09

Hi all, (I'm writing this to several lists since it involves GHC (implementation of extensions), cabal (registration of extensions) and some future Haskell standard (formalisation of extensions).) In my quest to implement all known syntactic extensions to Haskell in my haskell-src-exts package, I've become painfully aware of the sometimes ad-hoc nature that these extensions have been added to GHC. This should not be taken as criticism per se, GHC is awesome and I'm sure a lot of thought and research has gone into all of these extensions. I think the problem (from my point of view) is rather that most of the extensions are only really "interesting" on a type system level, whereas the syntactic level is rather trivial, and thus the latter has (rightly) gotten far less formal attention. I hope my putting the light on these issues will be a help and a kickoff towards improving the state of formalisation of the known and registered (with Cabal) extensions. One of the most blatant and (to me) problematic such issues is the matter of using 'forall'. GHC has a number of extensions relating to the use of forall-quantified types in various interesting ways. With none of these extensions on, forall is not considered a keyword, so the syntax with explicit forall quantification cannot be used at all ('forall' is considered a varid). However, with *any* extension on that relates to forall-quantified types, forall is a keyword, and can syntactically be used in types *anywhere*. This doesn't mean all such types will pass the type checker, most of them won't in fact, but syntactically there is really no (or at least very little) difference. Conceptually, all of these extensions (specifically PolymorphicComponents, Rank2Types, RankNTypes, LiberalTypeSynonyms and ScopedTypeVariables (and strangely also ExistentialQuantification)) thus have one thing in common. They all enable syntactically forall-quantified types. They allow different uses of these types as far as the type system is concerned, but syntactically there is no difference between type and type (in fact there cannot be, as I discussed in a recent blog post [1]). Funnily enough there are also some uses of forall-quantified types that are common to all of these extensions - using a forall just to make polymorphism explicit in a type doesn't change anything as far as the type system is concerned, so e.g. the types '(Eq a) => a -> Bool' and 'forall a . (Eq a) => a -> Bool' are equivalent. The latter type can be given to a function when any of the listed six extensions are given, even if most of them have nothing to do with this at all! So, what I'm getting at is an idea that Isaac Dupree gave as a comment to my blog post. He said: "I wish there was a plain old ExplicitForall extension that enabled the keyword in types (without extending the type checker -- only like (id :: forall a. a -> a) would be allowed)". I think this is a really great idea. I find it conceptually appealing, since I think it covers exactly that blind spot that is the seemingly unintended intersection between all these extensions. And it also makes the separation of concern between the syntactic level and the type system more clear. Any formalisation of any of the type system extensions would not need to bother with syntactic details, but can simply be said to imply ExplicitForall. I would thus like to propose the following formalisation of the ExplicitForall extension: ========================================= ExplicitForall enables the use of the keyword 'forall' to make a type explicitly polymorphic. Syntactically, it would mean the following change to Haskell 98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: type -> 'forall' tyvars '.' type | context '=>' type | ftype ftype -> btype '->' type | btype gendecl -> vars '::' type It does not allow the use of explicitly polymorphic types in any way not already allowed by Haskell 98 for implicitly polymorphic types. ========================================= One thing to note is that I haven't touched the matter of ExistentialQuantification in the above. Syntactically this is a different beast entirely, and could well be handled separately, though it's really an artifact of the way we (by default) write our data type declarations. Using GADT-style declarations, existential quantification goes nicely along with the others by following the same syntactic rules for types, even though from a type system it is of course still quite different from the rest. But with the ordinary Haskell 98 declaration style, we could define the syntactic part of the ExistentialQuantification extension as the following: ========================================= ExistentialQuantification allows data constructors to take existentially quantified arguments. Syntactically, it means the following changes to Haskell98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: constrs -> econstr_1 '|' ... '|' econstr_n econstr -> ['forall' tyvars '.' [context '=>']] constr ========================================= My hope is that you'll all agree with me on the need and rationale for the ExplicitForall extension, and that my proposal for formalisation is good enough for adoption. I feel much less strongly about ExistentialQuantification, and would love to hear some more input on that matter, but I do think it needs to be addressed one way or the other. Thoughts? Cheers, /Niklas [1] http://nibrofun.blogspot.com/2009/06/whats-in-forall.html

3 4

better generation of vi ctags in ghci
by Peter Hercek 02 Jul '09

02 Jul '09

Hi GHC and VI users, I got frustrated with vi tags not working after some unrelated code is edited in a source file. Moreover non-exported top level declarations were not available in vi tags file. Here is an attempt to fix it: http://www.hck.sk/users/peter/pub/ghc/betterCTags.patch Why would you want the new implementation of :ctags ghci command? * Tags are searched based on the line content. This is what Exuberant Ctags do for other languages and it is the other posix way to do it. This makes the positioning to work well even when the source code was edited (on places unrelated to the tag location). More complicated Ex statements can be used to improve it even more but then it does not work well with :tselect (it screws up tag kinds, at least with my version of vim 7.2.65). * All top level symbols defined in a module are added to the tags file. Even the non-exported ones. These are marked as static (file:) so the default tag selection (Ctrl-]) works fine based on the file you started the search from. * Tags get kinds added so you can select whether you want to get to a type constructor or a data constructor (that is if you share names between the two). * In general it is a nice addition to vim haskellmode. If you search for help on symbols in libraries then opening haddock is cool. If you search for help on a symbol in your project then opening the tag in a preview window (Ctrl-W} or ptselect) is cool. Problems: * It needs somebody to check that emacs tags were not broken. I'm not an emacs user but some tag generation code is shared for vim and emacs. I tried to keep emacs tags exactly the way they were (only the exported symbols, original file format). * If your code happens to have definitions on lines which happen to exist more times in one source file then it may put you at an incorrect location. I doubt it will ever happen but if anybody thinks it is really bad we can keep the original format of vim tags too. Then e.g. :ctags would generate tags with line numbers and :ctags! would generate tags with search expressions. If there is any support for this and ghc team decides to merge it I can provide darcs patch. I can do changes needed to get it merged. Peter.

3 5

Fwd: exposing hidden packages with runghc
by Iain Barnett 30 Jun '09

30 Jun '09

I think I posted this to the wrong list (libraries), so I've forwarded it here. ---- I'm trying to install HTTP-3000.0.0 (because I don't have cabal-install, and it's a dependency for cabal-install 0.4.9) This is on a Debian 5.1 machine with GHC 6.8.2 and 6.8.3 on it. The command: sudo runghc Setup configure -p && sudo runghc Setup build && sudo runghc Setup install The error: Could not find module `Data.Array.MArray': it is a member of package array-0.1.0.0, which is hidden ghc-pkg does list the hidden package. I've seen other threads on this "hiding" problem and searched through the GHC user guide, but I haven't actually found a solution, just explanation. I've tried sending the -package flag through to GHC by adding it to the runghc command, but I'm not doing this right, obviously. Would someone be able to point me in the right direction? It would be much appreciated. Iain

2 1

6.12.1 planning
by Simon Marlow 30 Jun '09

30 Jun '09

Hi Folks, As usual, we're planning a major release of GHC around September. Here's our list of the main items currently scheduled for 6.12.1, and their status. If you have the time and inclination to help with any of these, please get involved! * Parallel performance. 6.12.1 will ship with the improvements to parallel performance described in our ICFP 2009 paper. Still to do: overhaul the +RTS GC settings, tune for good performance by default. * Parallel profiling: the new RTS tracing features will be included, and we hope to have a release of ThreadScope to coincide with GHC 6.12.1. ThreadScope is written using gtk2hs, and could benefit from someone with expertise in producing polished gtk2hs apps - if you can lend a hand, contact Satnam Singh <satnams(a)microsoft.com>. * Unicode I/O: the new Unicode I/O library is in, and will ship with 6.12.1. Still to do: decide on the public API for changing encodings and newline conversion. * Shared libraries: we intend to ship with shared library support on at least x86/Linux and x86-64/Linux. There are various tasks remaining to do here - Duncan, can we have a summary? * Data Parallel Haskell. Manuel, can you comment on the state of play? What can we expect in time for 6.12.1? * Plugin support in GHC. The patches are not yet in GHC, and as far as I know are awaiting review - Simon, can you say more? * The new backend code generator. At the moment, it seems unlikely that GHC 6.12.1 will ship with the new code generator enabled by default, although it may well be available for testing. Meanwhile, work on it continues. The smaller items are all embodied in tickets, here are the tickets currently in the 6.12.1 milestone (135): http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… and on the 6.12 branch (251): http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… I estimate there are 2 man years of work here - needless to say, we aren't going to fix all these tickets :) As usual, if you want to vote for something, add your email to the CC field of the ticket. Several of these tickets would make good tasks for a fledgling GHC hacker. e.g. http://hackage.haskell.org/trac/ghc/ticket/2362 (allow full import syntax in GHCi) has a lot of support, and is a nice self-contained task (but not a small one). Even if you're not a GHC hacker you can still help, e.g. by helping to narrow down the cause of a bug, or verifying a bug on your platform. Let me remind people that GHC HEAD has the new build system, and it's actually rather pleasant to work with. Even if you have no idea what you're doing, you can always say 'make' at the top level and the build system will figure out what needs doing (ok, so that's what build systems are supposed to do, but GHC's has never quite managed it until now!). Cheers, Simon

3 2

Re: group keyword with TransformListComp
by Neil Mitchell 30 Jun '09

30 Jun '09

Hi, The question of syntax is always something that provokes intense discussion. My interest (and concern) with the choice of syntax in this case is three-fold: 1) I want HLint to turn on as many Haskell extensions as possible when parsing, with the trade off that they don't break a massive number of existing programs. For each extension I have weighed up the number of programs that will get broken (because the extension steals previously valid syntax), vs the number that will be parsed (how popular the extension is). I've erred on the side of enabling extensions, so am happy to accept changes in meaning for a!b and $(a). Almost all extensions get turned on, with the exception of TransformListComp, which even breaks the source code to HLint itself - something no other extension does. It seems the syntax stolen is far too much, especially when compared to other extensions. 2) I want to use TransformListComp in HLint. In particular, I have a nested pile of group/sort surrounding a list comp that would be perfect for TransformListComp. However, as it stands, I can't even enable the extension without that file breaking. I could qualify all the uses of group, but that seems too much hassle. I'd really like to enable the extension (without modification), and then start converting each group-like list-comp one at a time. 3) We'll never be able to make TransformListComp enabled in future versions of Haskell' since we break too many programs. It's an extension that is destined forever to remain only an extension. That seems like a lonely life for an extension. Thanks Neil On Sat, Jun 27, 2009 at 11:52 AM, Max Bolingbroke<omega.theta(a)gmail.com> wrote: > Hi, > > I agree this is annoying. It was hard to find syntax which was both > meaningful and currently unused, so we settled on this instead. As > Simon says, suggestions are welcome! > > Note that group *should* be parsed as a special id, so you can still > import D.L qualified and then use dot notation to access the function. > > Cheers, > Max > > > 2009/6/21 Neil Mitchell <ndmitchell(a)gmail.com>: >> Hi, >> >> The TransformListComp extension makes group a keyword. Unfortunately >> group is a useful function, and is even in Data.List. Thus, >> Data.List.group and TransformListComp are incompatible. This seems a >> very painful concession to give up a nice function name for a new >> extension. Is this intentional? Here's an example: >> >>> $ cat GroupKeyword.hs >>> {-# LANGUAGE TransformListComp #-} >>> module GroupKeyword where >>> >>> a = map head $ group $ sort [1..100] >>> $ ghci GroupKeyword.hs >>> GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help >>> Loading package ghc-prim ... linking ... done. >>> Loading package integer ... linking ... done. >>> Loading package base ... linking ... done. >>> [1 of 1] Compiling GroupKeyword ( GroupKeyword.hs, interpreted ) >>> >>> GroupKeyword.hs:4:15: parse error on input `group' >>> Failed, modules loaded: none. >>> Prelude> >> >> There are some places I'd like to use TransformListComp, but I often >> want to use group in the same module. >> >> Thanks >> >> Neil >> >

2 1

finalizers on handles
by Ganesh Sittampalam 29 Jun '09

29 Jun '09

Hi, I recently spent a while debugging a problem where a program deadlocked in the non-threaded runtime, but ran fine in the threaded runtime, despite the program having no blocking FFI calls, and boiled it down to the following test case: module Main(main) where import System import System.IO import System.Process main = do (ih, oh, _, _) <- runInteractiveProcess "cat" [] Nothing Nothing comphszp <- hGetContents oh print (length comphszp) -- hClose ih -- with this line they both deadlock The reason for the deadlock is fairly straightforward; since ih isn't closed before comphszp is fully demanded, no progress can be made. My guess is that the threaded runtime is fine because ih is dead at that point, and the finalizer for ih gets a chance to run, closing ih. If I'm right, is it really sensible for every handle to have this finalizer? Closing a pipe has externally visible side effects beyond just the release of resources, so it doesn't seem like it should happen non-deterministically. Cheers, Ganesh

4 11