From marlowsd at gmail.com Mon Jun 1 07:15:48 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 1 06:59:54 2009 Subject: ghc - force library search order In-Reply-To: References: Message-ID: <4A23B864.5070908@gmail.com> On 29/05/2009 15:19, John Lask wrote: > > ----- Original Message ----- From: "Duncan Coutts" > > To: "John Lask" > Sent: Friday, May 29, 2009 8:09 PM > Subject: Re: [Haskell-cafe] ghc - force library search order > > >> On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: >>> I need to force a library to be searched for unresolved symbols after >>> all >>> other libraries have been searched, and I would rather not resort to >>> constructing the linker command line directly. Is there a way to do >>> this? >>> >>> i.e. I want for example -lfoo to appear after all other haskell >>> libraries >>> and before system libraries (for example -lmsvcrt) once ghc has >>> constructed >>> the link command. i.e. how is it possible to coerce ghc into respecting >>> dependencies between the libraries. GHC does a good job in general with >>> native libraries, but there are allways corner cases. >>> >>> I have a feeling this is not possible, but it dosn't hurt to ask. No, there's currently no way to inject flags that come *after* the linker flags for the packages on the linker command line. It might help if you describe at a higher level what it is you're trying to do. There might be a better way to achieve it. Cheers, Simon From berthold at Mathematik.Uni-Marburg.de Mon Jun 1 17:08:50 2009 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Mon Jun 1 16:53:03 2009 Subject: IFL 2009 - 2nd Call for papers Message-ID: <4A244362.4030503@mathematik.uni-marburg.de> Apologies for multiple copies. Jost Berthold -------------- next part -------------- Call for Papers IFL 2009 Seton Hall University SOUTH ORANGE, NJ, USA http://tltc.shu.edu/blogs/projects/IFL2009/ ** NEW ** Accomodations information available: http://tltc.shu.edu/blogs/projects/IFL2009/accommodations.html Jane Street Capital has joined IFL 2009 as a sponsor ********* The 21st International Symposium on Implementation and Application of Functional Languages, IFL 2009, will be held for the first time in the USA. The hosting institution is Seton Hall University in South Orange, NJ, USA and the symposium dates are September 23-25, 2009. It is our goal to make IFL a regular event held in the USA and in Europe. The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2009 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2009 will use a post-symposium review process to produce a formal proceedings which will be published by Springer in the Lecture Notes in Computer Science series. All participants in IFL 2009 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. These submissions will be screened by the program committee chair to make sure they are within the scope of IFL and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full arcticle for the formal review process. These revised submissions will be reviewed by the program committee using prevailing academic standards to select the best articles that will appear in the formal proceedings. TOPICS IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools. If you are not sure if your work is appropriate for IFL 2009, please contact the PC chair at ifl2009@shu.edu. Topics of interest include, but are not limited to: language concepts type checking contracts compilation techniques staged compilation runtime function specialization runtime code generation partial evaluation (abstract) interpretation generic programming techniques automatic program generation array processing concurrent/parallel programming concurrent/parallel program execution functional programming and embedded systems functional programming and web applications functional programming and security novel memory management techniques runtime profiling and performance measurements debugging and tracing virtual/abstract machine architectures validation and verification of functional programs tools and programming techniques FP in Education PAPER SUBMISSIONS Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series format and not exceed 16 pages. The draft proceedings will appear as a technical report of the Department of Mathematics and Computer Science of Seton Hall University. IMPORTANT DATES Registration deadline August 15, 2009 Presentation submission deadline August 15, 2009 IFL 2009 Symposium September 23-25, 2009 Submission for review process deadline November 1, 2009 Notification Accept/Reject December 22, 2009 Camera ready version February 1, 2010 PROGRAM COMMITTEE Peter Achten University of Nijmegen, The Netherlands Jost Berthold Philipps-Universit?t Marburg, Germany Andrew Butterfield University of Dublin, Ireland Robby Findler Northwestern University, USA Kathleen Fisher AT&T Research, USA Cormac Flanagan University of California at Santa Cruz, USA Matthew Flatt University of Utah, USA Matthew Fluet Toyota Technological Institute at Chicago, USA Daniel Friedman Indiana University, USA Andy Gill University of Kansas, USA Clemens Grelck University of Amsterdam/Hertfordshire, The Netherlands/UK Jurriaan Hage Utrecht University, The Netherlands Ralf Hinze Oxford University, UK Paul Hudak Yale University, USA John Hughes Chalmers University of Technology, Sweden Patricia Johann University of Strathclyde, UK Yukiyoshi Kameyama University of Tsukuba, Japan Marco T. Moraz?n (Chair) Seton Hall University, USA Rex Page University of Oklahoma, USA Fernando Rubio Universidad Complutense de Madrid, Spain Sven-Bodo Scholz University of Hertfordshire, UK Manuel Serrano INRIA Sophia-Antipolis, France Chung-chieh Shan Rutgers University, USA David Walker Princeton University, USA Vikt?ria Zs?k E?tv?s Lor?nd University, Hungary PETER LANDIN PRIZE The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 euros. From jvlask at hotmail.com Mon Jun 1 19:30:28 2009 From: jvlask at hotmail.com (John Lask) Date: Mon Jun 1 19:16:51 2009 Subject: ghc - force library search order References: <4A23B864.5070908@gmail.com> Message-ID: I hav a module that depends upon (binds to) the microsoft uuid.lib (libuuid.a) this is a static library which exports some labels such as IID_IPersistFile. I was playing around with trying to get it to work both with normal compiling via ghc and to dynamically load in ghci. As we know, ghci can't load static libraries and so was not able to resolve the linkage. I therefore decided to directly incorporate the objects of (libuuid.a) into the haskell .a and ghci .o file (ghci) . To do this I needed to ject --whole-archive libuuid.a --no-whole-archive (or alternatively the list of objects) into the link command at an appropriate point to enable the resolution of the linkage. I have achieved my goal but only by constructing the list of objects to link entirely manually, constructing both the .a and .o for the haskell library manually. I am not satisfied with this solution as it is fragile wrt changes in the module structure of the library I have constructed. jvl ----- Original Message ----- From: "Simon Marlow" To: "John Lask" Cc: Sent: Monday, June 01, 2009 9:15 PM Subject: Re: ghc - force library search order > On 29/05/2009 15:19, John Lask wrote: >> >> ----- Original Message ----- From: "Duncan Coutts" >> >> To: "John Lask" >> Sent: Friday, May 29, 2009 8:09 PM >> Subject: Re: [Haskell-cafe] ghc - force library search order >> >> >>> On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: >>>> I need to force a library to be searched for unresolved symbols after >>>> all >>>> other libraries have been searched, and I would rather not resort to >>>> constructing the linker command line directly. Is there a way to do >>>> this? >>>> >>>> i.e. I want for example -lfoo to appear after all other haskell >>>> libraries >>>> and before system libraries (for example -lmsvcrt) once ghc has >>>> constructed >>>> the link command. i.e. how is it possible to coerce ghc into respecting >>>> dependencies between the libraries. GHC does a good job in general with >>>> native libraries, but there are allways corner cases. >>>> >>>> I have a feeling this is not possible, but it dosn't hurt to ask. > > No, there's currently no way to inject flags that come *after* the linker > flags for the packages on the linker command line. > > It might help if you describe at a higher level what it is you're trying > to do. There might be a better way to achieve it. > > Cheers, > Simon > From duncan.coutts at worc.ox.ac.uk Tue Jun 2 05:38:25 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jun 2 05:30:11 2009 Subject: [Fwd: OSX installer -- first draft] Message-ID: <1243935505.29805.296.camel@localhost> 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 > To: haskell-platform > 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.pkg > > 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. From marlowsd at gmail.com Tue Jun 2 06:43:05 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 2 06:27:09 2009 Subject: ghc - force library search order In-Reply-To: References: <4A23B864.5070908@gmail.com> Message-ID: <4A250239.8040803@gmail.com> On 02/06/2009 00:30, John Lask wrote: > I hav a module that depends upon (binds to) the microsoft uuid.lib > (libuuid.a) this is a static library which exports some labels such as > IID_IPersistFile. I was playing around with trying to get it to work > both with normal compiling via ghc and to dynamically load in ghci. As > we know, ghci can't load static libraries and so was not able to resolve > the linkage. I therefore decided to directly incorporate the objects of > (libuuid.a) into the haskell .a and ghci .o file (ghci) . To do this I > needed to ject --whole-archive libuuid.a --no-whole-archive (or > alternatively the list of objects) into the link command at an > appropriate point to enable the resolution of the linkage. > > I have achieved my goal but only by constructing the list of objects to > link entirely manually, constructing both the .a and .o for the haskell > library manually. I am not satisfied with this solution as it is fragile > wrt changes in the module structure of the library I have constructed. Right, GHCi doesn't work very well with static libraries. You can extract the contents of libuuid.a into a single .o file, and link this in - it sounds like that's what you're doing. In order to be able to use this without manual hackery, you will need to construct a Haskell package that only tries to link libuuid.a when in batch-linking mode (not GHCi). I think you can do this by given an empty extra-ghci-libraries field. And then you'll need to add uuid.o to the command line when starting GHCi. Cheers, Simon > > jvl > > ----- Original Message ----- From: "Simon Marlow" > To: "John Lask" > Cc: > Sent: Monday, June 01, 2009 9:15 PM > Subject: Re: ghc - force library search order > > >> On 29/05/2009 15:19, John Lask wrote: >>> >>> ----- Original Message ----- From: "Duncan Coutts" >>> >>> To: "John Lask" >>> Sent: Friday, May 29, 2009 8:09 PM >>> Subject: Re: [Haskell-cafe] ghc - force library search order >>> >>> >>>> On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: >>>>> I need to force a library to be searched for unresolved symbols after >>>>> all >>>>> other libraries have been searched, and I would rather not resort to >>>>> constructing the linker command line directly. Is there a way to do >>>>> this? >>>>> >>>>> i.e. I want for example -lfoo to appear after all other haskell >>>>> libraries >>>>> and before system libraries (for example -lmsvcrt) once ghc has >>>>> constructed >>>>> the link command. i.e. how is it possible to coerce ghc into >>>>> respecting >>>>> dependencies between the libraries. GHC does a good job in general >>>>> with >>>>> native libraries, but there are allways corner cases. >>>>> >>>>> I have a feeling this is not possible, but it dosn't hurt to ask. >> >> No, there's currently no way to inject flags that come *after* the >> linker flags for the packages on the linker command line. >> >> It might help if you describe at a higher level what it is you're >> trying to do. There might be a better way to achieve it. >> >> Cheers, >> Simon >> > From marlowsd at gmail.com Tue Jun 2 07:13:18 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 2 06:57:20 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <162772D134DA46E586DAB142369ECFE5@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net><2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> <4A1E7069.7010500@gmail.com> <162772D134DA46E586DAB142369ECFE5@cr3lt> Message-ID: <4A25094E.7020609@gmail.com> On 28/05/2009 15:09, Claus Reinke wrote: >>> One thing that wasn't available when this discussion was last active >>> is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions' >>> would be useful). For instance, appended below is the example from that >>> wiki page, with entirely local transformations to add source locations >>> and to use that info to augment 'ErrorCall' exceptions (we should really >>> augment 'PatternMatchFail' exception messages as well..). >>> >>> $ ghc -e main callstack.hs >>> : hd: empty list >>> ("callstack.hs",25) >>> ("callstack.hs",21) >>> ("callstack.hs",16) >>> ("callstack.hs",13) >> >> Your example is giving you the dynamic call stack. Is that really what >> you want? The dynamic call stack will often be quite different from >> the structure of your program, may well be surprising, and may even >> differ depending on compiler flags. > > Given the source locations, the lexical _position_ is obvious, You mean the call site? Yes, most methods will point you to the call site, since the top element of the dynamic stack is often the same as the top element of the dynamic stack (but not always). The call site on its own is often not enough, however - it's just one level of the stack. > so for mere > traces, dynamic seems to be the choice (with an option of pseudo-cbv > or the real dynamic stack). I don't know what pseudo-cbv is. And I claim the dynamic stack is almost never what you want. Ok, so there's one place you might want to see the dynamic stack: when catching exceptions raised by pure code. Then it really makes a difference whether something is evaluated or not, and you need a handle on the demand context in order to find out why an exception was raised. On the other hand, I think this case is relatively rare compared to cases of the form "finding out why my program called head []". > What is neither obvious nor provided (dynamic > or static, in any of the proposed stack traces) are the parameters for the > stack. If those are available, as in a debugger, the balance might shift to > favour lexical stack, especially if I'm investigating "what is there?", > rather > than "who asked for this, and why?", "where am I?" or "how did I get > there?". Sure, providing access to free variables is certainly desirable, but I think it's an orthogonal issue. There are engineering difficulties, such as introduction of space leaks. > Here are the +RTS -xc and mapException outputs together (when I > remove the mapError annotations, only the first <..> is printed, so > that is the part to focus on, the rest is confusion) - they seem to > complement each other (-xc has no locations, but names for the > lexical stack; mapError has no names, but locations for the dynamic > stack; we're still missing the parameters for either stack): I'm not claiming that +RTS -xc in its present form is what you want. I'm interested in finding an underlying mechanism that allows the right information to be obtained; things like source locations and free variables are just decoration. Now, most of the existing methods have problems with CAFs. I doubt that the problems with CAFs are fixable using the source-to-source transformation methods, but I think they might be fixable using cost-centre stacks. Cheers, Simon From marlowsd at gmail.com Tue Jun 2 07:57:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 2 07:41:13 2009 Subject: Job for someone: make a VM image for GHC development Message-ID: <4A251397.8070704@gmail.com> 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 From phercek at gmail.com Tue Jun 2 15:34:23 2009 From: phercek at gmail.com (Peter Hercek) Date: Tue Jun 2 15:18:40 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <4A25094E.7020609@gmail.com> References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net><2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt> <4A1E7069.7010500@gmail.com> <162772D134DA46E586DAB142369ECFE5@cr3lt> <4A25094E.7020609@gmail.com> Message-ID: <4A257EBF.10309@gmail.com> Simon Marlow wrote: > On 28/05/2009 15:09, Claus Reinke wrote: >> so for mere >> traces, dynamic seems to be the choice (with an option of pseudo-cbv >> or the real dynamic stack). > > I don't know what pseudo-cbv is. And I claim the dynamic stack is > almost never what you want. > > Ok, so there's one place you might want to see the dynamic stack: when > catching exceptions raised by pure code. Would it not help also when finding out why some code is not as lazy as it is hoped for? Now, I do not know how often this problem happens, I did not have it yet, but it looks like it would help. I remember I also wanted it when I was trying to understand how uulib works. I would expect it to be useful anytime laziness is critical for efficient program execution. If the stacks do not come with variables in the scope available then both are useful about the same from my rather unexperienced point of view. Anyway, after I'd learned to use GhciExt (thank you both for helping me out with it), the next command became more important to me than the stack. That is for my code, if/when I get to uulib again I may change my mind quickly :-D Peter. From Axel.Simon at ens.fr Tue Jun 2 17:19:03 2009 From: Axel.Simon at ens.fr (Axel Simon) Date: Tue Jun 2 17:03:16 2009 Subject: Problem with profiling In-Reply-To: <1243797657.27787.36.camel@zezinho> References: <1243797657.27787.36.camel@zezinho> Message-ID: <8BF3C3BE-080E-4F9B-9E2E-9031B6681109@di.ens.fr> On May 31, 2009, at 21:20, Marco T?lio Gontijo e Silva wrote: > Hello, > > recently there was a thread about a problem in profiling in > gtk2hs-users, and it was menitoned that this could be a GHC6 bug. > > The problem is described in > http://sourceforge.net/mailarchive/forum.php? > thread_name=1242762143.18742.277.camel%40zezinho&forum_name=gtk2hs- > users . > > Do you think this is a gtk2hs specific problem, or is it something > about > GHC? > Are you sure that you compiled from scratch, i.e. did you do a 'make distclean'? You could try to give --disable-split-objs to configure and see if that helps. Axel. From fox at ucw.cz Wed Jun 3 05:58:51 2009 From: fox at ucw.cz (Milan Straka) Date: Wed Jun 3 05:59:26 2009 Subject: Choosing implementation depending on class instances using rewriting rules Message-ID: <20090603095850.GA21239@atrey.karlin.mff.cuni.cz> Hi, I am interesting in writing a method nub in such a way, that it will use O(N^2) trivial algorithm for types with equality only, and O(N log N) algorithm for comparable types. I would like to say class Nub where nub :: [a] -> [a] instance Ord a => Nub a where nub = nubOrd instance Eq a => Nub a where nub = nubEq which is of course not valid Haskell. I tried using GHC rewriting rules to achieve this. My first try was {-# NOINLINE nub #-} nub :: Eq a => [a] -> [a] nub xs = ... nubOrd :: Ord a => [a] -> [a] nubOrd xs = ... {-# RULES "nub/nubOrd" nub = nubOrd #-} which does not work either, because of missing an Ord a context. I was not able to write the rule which would fire. Is there a way to write such a rewriting rule or there is no way of acquiring the Ord dictionary in rewrite rule? Or does anyone know any other way of implementing such a nub without explicitly listing all Ord instances? I wish you a nice day, Milan Straka PS: Listing {-# RULES "nub/nubOrd Int" nub = nubOrd :: [Int]->[Int] #-} for all Ord instances would work, but ... From niklas.broberg at gmail.com Wed Jun 3 07:17:14 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 3 07:01:11 2009 Subject: Choosing implementation depending on class instances using rewriting rules In-Reply-To: <20090603095850.GA21239@atrey.karlin.mff.cuni.cz> References: <20090603095850.GA21239@atrey.karlin.mff.cuni.cz> Message-ID: Hi Milan, > Is there a way to write such a rewriting rule or there is no way of acquiring > the Ord dictionary in rewrite rule? Or does anyone know any other way > of implementing such a nub without explicitly listing all Ord instances? Have a look at http://okmij.org/ftp/Haskell/types.html#class-based-dispatch Cheers, /Niklas From marlowsd at gmail.com Wed Jun 3 08:32:46 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 3 08:16:46 2009 Subject: Problem with profiling In-Reply-To: <8BF3C3BE-080E-4F9B-9E2E-9031B6681109@di.ens.fr> References: <1243797657.27787.36.camel@zezinho> <8BF3C3BE-080E-4F9B-9E2E-9031B6681109@di.ens.fr> Message-ID: <4A266D6E.2010803@gmail.com> On 02/06/2009 22:19, Axel Simon wrote: > > On May 31, 2009, at 21:20, Marco T?lio Gontijo e Silva wrote: > > $ ghc --make -prof glib.hs > > I'm getting: > > [1 of 1] Compiling Main ( glib.hs, glib.o ) > Linking glib ... > /usr/lib/gtk2hs/libHSgio_p.a(File.p_o): In function `s8ds_info': > (.text+0x71c9): undefined reference to `SystemziGIOziFile_d3Bh' > collect2: ld returned 1 exit status > > Do you know what could be causing this? SystemziGIOziFile_d3Bh looks like a symbol from a _stub.o file. Perhaps when the gtk2hs build system didn't put the _stub.o files in the libHSgio_p.a library? Cheers, Simon From niklas.broberg at gmail.com Wed Jun 3 10:41:59 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 3 10:33:24 2009 Subject: Three patches for cabal Message-ID: (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 -------------- next part -------------- A non-text attachment was scrubbed... Name: GeneralizedListComp-et-al.dpatch Type: application/octet-stream Size: 38047 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090603/67938aa4/GeneralizedListComp-et-al-0001.obj From batterseapower at hotmail.com Wed Jun 3 11:33:19 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Jun 3 11:17:16 2009 Subject: Three patches for cabal In-Reply-To: References: Message-ID: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> 2009/6/3 Niklas Broberg : > 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. It's called TransformListComp because the "then f" syntax transforms a list using f (which has type [a] -> [a]) - not because the implementation works by transformation or anything like that! We considered but rejected GeneralizedListComp because it's too vague - what if someone comes up with another list comprehension generalisation in the future? Max From pumpkingod at gmail.com Wed Jun 3 12:43:12 2009 From: pumpkingod at gmail.com (Daniel Peebles) Date: Wed Jun 3 12:27:08 2009 Subject: Choosing implementation depending on class instances using rewriting rules In-Reply-To: <20090603095850.GA21239@atrey.karlin.mff.cuni.cz> References: <20090603095850.GA21239@atrey.karlin.mff.cuni.cz> Message-ID: This isn't necessarily correct, is it? An equality-based (n^2) nub works "fine" on infinite lists, whereas any O(n log n) sort-based nub must necessarily evaluate the entire list before being able to return the value. The original n^2 nub also returns the elements in the order of their first appearance rather than sorted order. Of course, you may not care about this and just be experimenting with rewrite rules, in which case I can't help you :) Dan On Wed, Jun 3, 2009 at 5:58 AM, Milan Straka wrote: > Hi, > > I am interesting in writing a method nub in such a way, that it will > use O(N^2) trivial algorithm for types with equality only, and O(N log N) > algorithm for comparable types. I would like to say > > ?class Nub where nub :: [a] -> [a] > ?instance Ord a => Nub a where nub = nubOrd > ?instance Eq a => Nub a where nub = nubEq > > which is of course not valid Haskell. I tried using GHC rewriting rules > to achieve this. My first try was > > ?{-# NOINLINE nub #-} > ?nub :: Eq a => [a] -> [a] > ?nub xs = ... > > ?nubOrd :: Ord a => [a] -> [a] > ?nubOrd xs = ... > > ?{-# RULES "nub/nubOrd" nub = nubOrd #-} > > which does not work either, because of missing an Ord a context. I was not > able to write the rule which would fire. > > Is there a way to write such a rewriting rule or there is no way of acquiring > the Ord dictionary in rewrite rule? Or does anyone know any other way > of implementing such a nub without explicitly listing all Ord instances? > > I wish you a nice day, > Milan Straka > > PS: Listing {-# RULES "nub/nubOrd Int" nub = nubOrd :: [Int]->[Int] #-} for > all Ord instances would work, but ... > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From niklas.broberg at gmail.com Wed Jun 3 13:49:50 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 3 13:33:45 2009 Subject: Three patches for cabal In-Reply-To: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> References: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> Message-ID: > It's called TransformListComp because the "then f" syntax transforms a > list using f (which has type [a] -> [a]) - not because the > implementation works by transformation or anything like that! We > considered but rejected GeneralizedListComp because it's too vague - > what if someone comes up with another list comprehension > generalisation in the future? I see, my mistake in interpreting the naming. However, I really don't agree this is a good choice. This feature is documented and refered to all over the place as general(ised) list comprehension, whereas a google search for either of the terms "transform list comprehension" or "tranformation list comprehension", with quotes, returns zilch (and without quotes returns nothing Haskellish). It seems clear to me that we need to either do the change I propose, which I think goes best with the principle of least surprise, or rewrite the GHC documentation at the very least. I can agree that generalised list comprehension could be a bit too vague to be future sensitive - but I'd rather cross that bridge when we get there! Cheers, /Niklas From dave at zednenem.com Wed Jun 3 15:59:07 2009 From: dave at zednenem.com (David Menendez) Date: Wed Jun 3 15:43:02 2009 Subject: [Fwd: OSX installer -- first draft] In-Reply-To: <1243935505.29805.296.camel@localhost> References: <1243935505.29805.296.camel@localhost> Message-ID: <49a77b7a0906031259o3b543101vd8199d61d136e249@mail.gmail.com> On Tue, Jun 2, 2009 at 5:38 AM, Duncan Coutts wrote: > 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 Is this a universal binary, or Intel-only? > 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. Will there be some integration with the existing distribution schemes for Mac OS X (fink and macports), or are end users expected to use cabal install? -- Dave Menendez From sebf at informatik.uni-kiel.de Wed Jun 3 17:26:39 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Wed Jun 3 17:10:47 2009 Subject: space leak due to optimisations and/or newtypes Message-ID: 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.) From marcot at holoscopio.com Wed Jun 3 17:51:34 2009 From: marcot at holoscopio.com (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Wed Jun 3 17:36:29 2009 Subject: Problem with profiling In-Reply-To: <8BF3C3BE-080E-4F9B-9E2E-9031B6681109@di.ens.fr> References: <1243797657.27787.36.camel@zezinho> <8BF3C3BE-080E-4F9B-9E2E-9031B6681109@di.ens.fr> Message-ID: <1244065894.11598.84.camel@zezinho> Hello Axel. Em Ter, 2009-06-02 ?s 23:19 +0200, Axel Simon escreveu: > On May 31, 2009, at 21:20, Marco T?lio Gontijo e Silva wrote: (...) > > recently there was a thread about a problem in profiling in > > gtk2hs-users, and it was menitoned that this could be a GHC6 bug. > > > > The problem is described in > > http://sourceforge.net/mailarchive/forum.php? > > thread_name=1242762143.18742.277.camel%40zezinho&forum_name=gtk2hs- > > users . > > > > Do you think this is a gtk2hs specific problem, or is it something > > about > > GHC? > > > > Are you sure that you compiled from scratch, i.e. did you do a 'make > distclean'? You could try to give --disable-split-objs to configure > and see if that helps. I build from a just extracted tree. Should I do make distclean just after extracting the .tar.gz? Greetings. -- marcot http://marcot.iaaeee.org/ From duncan.coutts at worc.ox.ac.uk Wed Jun 3 19:38:03 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 3 19:22:05 2009 Subject: Three patches for cabal In-Reply-To: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> References: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> Message-ID: <1244072283.29805.458.camel@localhost> On Wed, 2009-06-03 at 16:33 +0100, Max Bolingbroke wrote: > 2009/6/3 Niklas Broberg : > > 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. > > It's called TransformListComp because the "then f" syntax transforms a > list using f (which has type [a] -> [a]) - not because the > implementation works by transformation or anything like that! We > considered but rejected GeneralizedListComp because it's too vague - > what if someone comes up with another list comprehension > generalisation in the future? In that case can the documentation, eg in the ghc user guide[1] be updated to use the new name. It's jolly confusing to go looking for the extension name corresponding to the extension. The ghc user guide section on it calls it generalised and mentions no flag or extension name. We initially thought that the extension had never been registered and I only found it by accident when looking in the reference section of the ghc user guide on flag names[2] I noticed that "transform list comprehensions" actually links to the section on generalise list comprehensions. Duncan [1] http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#generalised-list-comprehensions [2] http://haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2949842 From dinko.tenev at gmail.com Thu Jun 4 02:32:40 2009 From: dinko.tenev at gmail.com (Dinko Tenev) Date: Thu Jun 4 02:16:35 2009 Subject: Choosing implementation depending on class instances using rewriting rules In-Reply-To: References: <20090603095850.GA21239@atrey.karlin.mff.cuni.cz> Message-ID: On Wed, Jun 3, 2009 at 7:43 PM, Daniel Peebles wrote: > An equality-based (n^2) nub > works "fine" on infinite lists, whereas any O(n log n) sort-based nub > must necessarily evaluate the entire list before being able to return > the value. No. You just need to keep anything seen so far in a container with O( log n ) insert/lookup times. > The original n^2 nub also returns the elements in the order > of their first appearance rather than sorted order. Where exactly did sorted order come in? D From simonpj at microsoft.com Thu Jun 4 03:43:47 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jun 4 03:27:43 2009 Subject: Three patches for cabal In-Reply-To: <1244072283.29805.458.camel@localhost> References: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> <1244072283.29805.458.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC888CDB@EA-EXMSG-C334.europe.corp.microsoft.com> I'd be quite happy to rename the flag to GeneralisedisedListComp, and clarify the user manual. Would that suit everyone? I suppose the alternative is to leave it as TransformListComp, and document that fact. But I rather agree that GeneralisedListComp fits the literature better. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Duncan Coutts | Sent: 04 June 2009 00:38 | To: Max Bolingbroke | Cc: GHC-users; Haskell Libraries | Subject: Re: Three patches for cabal | | On Wed, 2009-06-03 at 16:33 +0100, Max Bolingbroke wrote: | > 2009/6/3 Niklas Broberg : | > > 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. | > | > It's called TransformListComp because the "then f" syntax transforms a | > list using f (which has type [a] -> [a]) - not because the | > implementation works by transformation or anything like that! We | > considered but rejected GeneralizedListComp because it's too vague - | > what if someone comes up with another list comprehension | > generalisation in the future? | | In that case can the documentation, eg in the ghc user guide[1] be | updated to use the new name. It's jolly confusing to go looking for the | extension name corresponding to the extension. The ghc user guide | section on it calls it generalised and mentions no flag or extension | name. We initially thought that the extension had never been registered | and I only found it by accident when looking in the reference section of | the ghc user guide on flag names[2] I noticed that "transform list | comprehensions" actually links to the section on generalise list | comprehensions. | | Duncan | | [1] | http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#generalised- | list-comprehensions | [2] | http://haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2949842 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Thu Jun 4 04:05:56 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jun 4 03:49:53 2009 Subject: space leak due to optimisations and/or newtypes In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC888D09@EA-EXMSG-C334.europe.corp.microsoft.com> It sounds like a bad performance bug to me! Newtypes should not cost efficiency. Please to submit a Trac bug report. What would really help is a self-contained program that demonstrates the problem. Maybe that's what you've supplied. I'm confused though. You say 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. Are you also saying this? If I leave all of them in, then the program takes ages and uses lots of space, if I use -O. But it's fine without -O. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Sebastian Fischer | Sent: 03 June 2009 22:27 | To: glasgow-haskell-users@haskell.org | Subject: space leak due to optimisations and/or newtypes | | 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.) | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From sebf at informatik.uni-kiel.de Thu Jun 4 04:16:52 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Thu Jun 4 04:00:51 2009 Subject: space leak due to optimisations and/or newtypes In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337FC888D09@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C337FC888D09@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Jun 4, 2009, at 10:05 AM, Simon Peyton-Jones wrote: > What would really help is a self-contained program that demonstrates > the problem. Maybe that's what you've supplied. I'm confused > though. You say > 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. > > Are you also saying this? > If I leave all of them in, then the program takes ages and uses > lots of space, if I use -O. But it's fine without -O. Yes exactly, that is what happens with the program I attached. Morover, my original program uses lots of memory with and without -O (but it's fine without newtypes). I'll file a Trac bug report and supply both the condensed and the original program. Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From marlowsd at gmail.com Thu Jun 4 05:42:45 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jun 4 05:26:42 2009 Subject: space leak due to optimisations and/or newtypes In-Reply-To: References: Message-ID: <4A279715.5000805@gmail.com> On 03/06/2009 22:26, Sebastian Fischer wrote: > ------- > {-# 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 > ------- Those two [1..] ring alarm bells. GHC will happily combine them with CSE and possibly also lift them to the top-level; both transformations might have a big impact on space behaviour. Try with -fno-full-laziness and/or -fno-cse. Cheers, Simon From sebf at informatik.uni-kiel.de Thu Jun 4 08:33:00 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Thu Jun 4 08:16:58 2009 Subject: space leak due to optimisations and/or newtypes In-Reply-To: <4A279715.5000805@gmail.com> References: <4A279715.5000805@gmail.com> Message-ID: On Jun 4, 2009, at 11:42 AM, Simon Marlow wrote: > Those two [1..] ring alarm bells. GHC will happily combine them > with CSE and possibly also lift them to the top-level; both > transformations might have a big impact on space behaviour. > > Try with -fno-full-laziness and/or -fno-cse. I did and found no difference when using any or both of these flags. I have just submitted a ticket: http://hackage.haskell.org/trac/ghc/ticket/3273 It seems the problem is not related to newtypes. Also in the original program with newtypes the memory requirements only depend on whether I use -O. Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From coreyoconnor at gmail.com Thu Jun 4 15:05:51 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Thu Jun 4 14:49:45 2009 Subject: Job for someone: make a VM image for GHC development In-Reply-To: <4A251397.8070704@gmail.com> References: <4A251397.8070704@gmail.com> Message-ID: On a related note: I have an amazon EC2 machine image* based on Ubuntu Server edition with the following set up: - GHC 6.10.3 + locally installed documentation - cabal install Which is, IMO, the baseline requirements of a haskell dev environment. What other packages would be useful? I'd imagine the setup for a VM image and an a Amazon EC2 image would have an identical base. Well, maybe the amazon EC2 image should use a server distro while the vm image a desktop distro? -Corey O'Connor * I don't know how to release the machine image such that it's paramaterized by a public/private key unique to the user. Once I figure that out I'll make sure it's public. On Tue, Jun 2, 2009 at 4:57 AM, Simon Marlow wrote: > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From sebf at informatik.uni-kiel.de Thu Jun 4 18:54:48 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Thu Jun 4 18:38:42 2009 Subject: space leak due to optimisations and/or newtypes In-Reply-To: References: <4A279715.5000805@gmail.com> Message-ID: <6C254FD6-A00F-40F0-9C8B-5BE1FAC1302D@informatik.uni-kiel.de> On Jun 4, 2009, at 2:33 PM, Sebastian Fischer wrote: >> Try with -fno-full-laziness and/or -fno-cse. > > I did and found no difference when using any or both of these flags. As "int-e" pointed out on the ticket that was my fault (spuriously abstracting from command-line argument order). -fno-full-laziness does avoid the space leak. Now that I am aware of let-floating I wonder why removing any of the occurrences of 'id' happens to avoid it. Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From duncan.coutts at worc.ox.ac.uk Thu Jun 4 19:57:12 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 4 20:25:37 2009 Subject: [Fwd: OSX installer -- first draft] In-Reply-To: <49a77b7a0906031259o3b543101vd8199d61d136e249@mail.gmail.com> References: <1243935505.29805.296.camel@localhost> <49a77b7a0906031259o3b543101vd8199d61d136e249@mail.gmail.com> Message-ID: <1244159832.29805.493.camel@localhost> On Wed, 2009-06-03 at 15:59 -0400, David Menendez wrote: > On Tue, Jun 2, 2009 at 5:38 AM, Duncan Coutts > wrote: > > 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 > > Is this a universal binary, or Intel-only? Like the existing ghc .pkg, it's Intel-only and requires OS X 10.5. > > 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. > > Will there be some integration with the existing distribution schemes > for Mac OS X (fink and macports), or are end users expected to use > cabal install? We hope that since fink and macports are essentially traditional unix ports systems that they'll provide haskell-platform meta-packages, just as we hope other linux/bsd distros will do. What we (the HP team) provide ourselves will be generic packages for unix (possibly generic binary packages for linux) and packages for the systems that have no distro system of their own, ie windows and os x (for non-macports/fink users). We also provide the specification for distro people to make native distro packages. Duncan From duncan.coutts at worc.ox.ac.uk Thu Jun 4 20:31:06 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 4 20:25:48 2009 Subject: Three patches for cabal In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C337FC888CDB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> <1244072283.29805.458.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C337FC888CDB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1244161866.29805.511.camel@localhost> On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-Jones wrote: > I'd be quite happy to rename the flag to GeneralisedisedListComp, and > clarify the user manual. Would that suit everyone? > > I suppose the alternative is to leave it as TransformListComp, and > document that fact. But I rather agree that GeneralisedListComp fits > the literature better. Looking at the paper, it doesn't really give it any specific name. Perhaps is a good thing because we can change the ghc user guide relatively easily, but not published papers. I appreciate Max's point that GeneralisedListComp is a bit vague, though TransformListComp doesn't really speak to me. I would not (and did not) guess it has any relation to the extension in question. My only other suggestion is QueryListComp or GeneralisedQueryListComp (bikeshed dangers approaching...). The main point is that the docs and the extension name should be consistent (and should refer to each other). Duncan From p.k.f.holzenspies at utwente.nl Fri Jun 5 03:46:26 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Fri Jun 5 03:30:09 2009 Subject: Job for someone: make a VM image for GHC development Message-ID: <1244187986.4439.20.camel@ewi1043> 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 From marlowsd at gmail.com Fri Jun 5 04:38:48 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jun 5 04:22:44 2009 Subject: Job for someone: make a VM image for GHC development In-Reply-To: <1244187986.4439.20.camel@ewi1043> References: <1244187986.4439.20.camel@ewi1043> Message-ID: <4A28D998.7090008@gmail.com> Hi Philip, Thanks for looking into this! On 05/06/2009 08:46, Philip K.F. H?lzenspies wrote: > 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. So there are lots of different things you could do. When I posted my message I had in mind setting up a VM image that had everything you need to hack on GHC itself, but I wasn't exactly clear about that - "GHC development environment" could mean an environment for developing Haskell code with GHC, and that's what I think most people thought I was on about. Nevertheless, both are useful. Perhaps a generic Haskell development environment as a VM image would be the most useful, but I'm thinking in particular about lowering the barrier to entry for those who want to do casual hacking GHC itself or its libraries, and for that the VM image needs to have a GHC source tree (or two) set up and ready to build. There's no reason you can't do it all: have a VM image with the Haskell Platform, darcs, full documentation, a couple of GHC trees, and all the tools you need to build and hack on GHC. That would be useful for both types of users. Though the size might be a problem - we might have to use something like bittorrent as a distribution mechanism rather than just putting it up on haskell.org. The other way is, as you suggest, to build a script that would install all the tools on top of a barebones Linux install. And such a thing is almost a necessity if we want to keep rolling out updated VM images from time to time. So I think that's a great way to start. Given this script we can use it to build pre-installed VM images too. Cheers, Simon From Christian.Maeder at dfki.de Fri Jun 5 04:50:51 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jun 5 04:34:46 2009 Subject: is the library iconv necessary for haskeline? Message-ID: <4A28DC6B.9030809@dfki.de> 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.bz2 and I was able to install http://hackage.haskell.org/packages/archive/haskeline/0.6.1.6/haskeline-0.6.1.6.tar.gz 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 From sebf at informatik.uni-kiel.de Fri Jun 5 05:04:02 2009 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Fri Jun 5 04:47:58 2009 Subject: Job for someone: make a VM image for GHC development In-Reply-To: <4A251397.8070704@gmail.com> References: <4A251397.8070704@gmail.com> Message-ID: On Jun 2, 2009, at 1:57 PM, Simon Marlow wrote: > We'd probably need to find a suitably minimal Linux install, or > start from an existing minimal Linux VM image. There is a german article [1] how to combine BusyBox [2] with a linux kernel to get a full (restricted, but small) linux system. Maybe this helps reducing the image size. There are english articles [3] on the web too. Cheers, Sebastian [1]: http://www.heise.de/ct/inhalt/2009/12/156/ [2]: http://www.busybox.net/about.html [3]: http://www.google.com/search?q=building+tiny+linux+systems+with+busybox -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From simonpj at microsoft.com Fri Jun 5 10:02:21 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jun 5 09:46:22 2009 Subject: Three patches for cabal In-Reply-To: <1244161866.29805.511.camel@localhost> References: <9d4d38820906030833m73429798h62f6842b2ccf6319@mail.gmail.com> <1244072283.29805.458.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C337FC888CDB@EA-EXMSG-C334.europe.corp.microsoft.com> <1244161866.29805.511.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FC91701F@EA-EXMSG-C334.europe.corp.microsoft.com> Since there has been little comment on this, my preliminary conclusion is that no one cares much what the flag is called. So I've left the flag unchanged, but make the manual mention it in the right place. If pressure builds to change the flag name, I'm happy to do so. Simon | -----Original Message----- | From: Duncan Coutts [mailto:duncan.coutts@worc.ox.ac.uk] | Sent: 05 June 2009 01:31 | To: Simon Peyton-Jones | Cc: Max Bolingbroke; Niklas Broberg; GHC-users; Haskell Libraries | Subject: RE: Three patches for cabal | | On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-Jones wrote: | > I'd be quite happy to rename the flag to GeneralisedisedListComp, and | > clarify the user manual. Would that suit everyone? | > | > I suppose the alternative is to leave it as TransformListComp, and | > document that fact. But I rather agree that GeneralisedListComp fits | > the literature better. | | Looking at the paper, it doesn't really give it any specific name. | Perhaps is a good thing because we can change the ghc user guide | relatively easily, but not published papers. | | I appreciate Max's point that GeneralisedListComp is a bit vague, though | TransformListComp doesn't really speak to me. I would not (and did not) | guess it has any relation to the extension in question. My only other | suggestion is QueryListComp or GeneralisedQueryListComp (bikeshed | dangers approaching...). | | The main point is that the docs and the extension name should be | consistent (and should refer to each other). | | Duncan | From judah.jacobson at gmail.com Fri Jun 5 12:35:59 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jun 5 12:19:50 2009 Subject: is the library iconv necessary for haskeline? In-Reply-To: <4A28DC6B.9030809@dfki.de> References: <4A28DC6B.9030809@dfki.de> Message-ID: <6d74b0d20906050935p21349c94jf139cfb2f7b281af@mail.gmail.com> On Fri, Jun 5, 2009 at 1:50 AM, Christian Maeder wrote: > 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.* > Haskeline always requires an iconv library when built on POSIX systems; OSes differ on whether that functionality is included as part of libc or whether you need to pass -liconv to gcc. However, my impression was that Solaris is part of the former category, so I'm not sure what's going wrong here. Can you please send the output of running "cabal install haskeline -v3" on Solaris (or, cd into the libraries/haskeline subdirectory and "runghc Setup configure -v3")? (Also, to avoid spamming the mailing list we should probably move this discussion to the haskeline bug tracker: http://trac.haskell.org/haskeline) > Under Linux I've installed successfully > http://www.haskell.org/ghc/dist/6.10.3/ghc-6.10.3-i386-unknown-linux-n.tar.bz2 > and I was able to install > http://hackage.haskell.org/packages/archive/haskeline/0.6.1.6/haskeline-0.6.1.6.tar.gz > without libiconv! > >> ./Setup configure > Configuring haskeline-0.6.1.6... > checking whether to use -liconv... not needed. Right, because on Linux iconv is included in libc. > However, the mere existence of /usr/local/lib/libiconv* files causes > configure to use -liconv: > > checking whether to use -liconv... using -liconv. I don't understand why that would happen on Linux; the Setup script prefers not using -liconv if possible (though use of -liconv can be forced with the -flibiconv flag). Can you send (or attach to a ticket) the output of "cabal configure -v3" in the situation you describe? Thanks, -Judah From coreyoconnor at gmail.com Sat Jun 6 17:09:18 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Sat Jun 6 16:53:05 2009 Subject: Help debugging a deadlock in salvia on GHC 6.10 i386 Message-ID: I'm working on trimming down the test code and filing a real bug. I'm going to list out what I know right now and if anything jumps out please let me know. Thanks! I'm running a webserver built using salvia [1] and GHC 6.10 [2]. I've trimmed down the code enough such that there is no obvious source of a deadlock in either salvia or the reset of the web server. I don't have any specific conditions that reproduce the issue as well. Just after some time, anywhere from a few minutes to a few hours, the server deadlocks. No particular request or number of requests seem to trigger the deadlock. 1) Salvia accepts connections on the main thread then forkIOs a new thread to actually handle the request. The new thread uses Handle based IO. 2) As I understand it, there are issues with forkProcess and Handle based IO. While this is a web server I'm avoiding using "daemonize" code that relies on forkProcess. no forkProcess is occurring that I know of. 3) The thread state summary printed by calling printAllThreads() from GDB is: all threads: threads on capability 0: other threads: thread 2 @ 0xb7d66000 is blocked on an MVar @ 0xb7d670b4 thread 3 @ 0xb7d74214 is blocked on an MVar @ 0xb7da88f0 4) The thread states according to a "thread apply all bt" from GDB is: 1. GDB backtrace Thread 4 (Thread 0xb7cffb90 (LWP 30891)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7cc1c, pMut=0x9a7cc4c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xb7cff36c, task=0x9a7cc00) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7cc00) at Schedule.c:293 #5 0x083ed5ff in workerStart (task=0x9a7cc00) at Schedule.c:1923 #6 0xb7fcc50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7f49a0e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb74feb90 (LWP 30892)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7ef3c, pMut=0x9a7ef6c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xb74fe36c, task=0x9a7ef20) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7ef20) at Schedule.c:293 #5 0x083ed5ff in workerStart (task=0x9a7ef20) at Schedule.c:1923 #6 0xb7fcc50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7f49a0e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb6cfdb90 (LWP 30916)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7e12c, pMut=0x9a7e15c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xb6cfd36c, task=0x9a7e110) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7e110) at Schedule.c:293 #5 0x083ed5ff in workerStart (task=0x9a7e110) at Schedule.c:1923 #6 0xb7fcc50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7f49a0e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb7e666b0 (LWP 30890)): #0 0xb8080416 in __kernel_vsyscall () #1 0xb7fd0075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x083f4320 in waitCondition (pCond=0x9a7cb3c, pMut=0x9a7cb6c) at posix/OSThreads.c:65 #3 0x0840de64 in yieldCapability (pCap=0xbfa822ac, task=0x9a7cb20) at Capability.c:506 #4 0x083eb292 in schedule (initialCapability=0x8565aa0, task=0x9a7cb20) at Schedule.c:293 #5 0x083ed463 in scheduleWaitThread (tso=0xb7d80800, ret=0x0, cap=0x8565aa0) at Schedule.c:1895 #6 0x083e851a in rts_evalLazyIO (cap=0x8565aa0, p=0x8489478, ret=0x0) at RtsAPI.c:517 #7 0x083e79d5 in real_main () at Main.c:111 Anybody think of anything so far? Cheers, Corey O'Connor From claus.reinke at talk21.com Sun Jun 7 07:23:57 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Jun 7 07:07:51 2009 Subject: Should exhaustiveness testing be on by default? References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net><2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt><4A1E7069.7010500@gmail.com><162772D134DA46E586DAB142369ECFE5@cr3lt> <4A25094E.7020609@gmail.com> Message-ID: <6F3C5B3D1F8B4315B7277B88E747BB62@cr3lt> >>>> One thing that wasn't available when this discussion was last active >>>> is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions' >>>> would be useful). >> so for mere traces, dynamic seems to be the choice (with an option of >> pseudo-cbv or the real dynamic stack). > > I don't know what pseudo-cbv is. oops, forward reference - explained later in the same email: pretend that evaluation is call-by-value and produce stack for that (instead of the actuall call-by-need stack which can be confusing). > And I claim the dynamic stack is almost never what you want. Maybe so - I'd be interested in an example on which this claim is based. Perhaps I've been misunderstanding what you mean by "lexical stack"? "lexical" to me implies only scope information, nothing related to run time call chains, which would be "dynamic". In the "dynamic" case, one can then distinguish between call-by-need stack (what actually happens in GHC) and call-by-value stack (pretend that everything is strict). What the cost-centre stack delivers appears to be more than scopes, and less than a full static call graph (which would have to include non deterministic branches, since the actual choice of branches depends on runtime information) - it seems to use runtime information to give a slice of the full call graph (eg, not all call sites that could call the current function, but only the one that did so in the current run)? >> Here are the +RTS -xc and mapException outputs together (.. >> - they seem to complement each other (-xc has no locations, but >> names for the lexical stack; mapError has no names, but locations >> for the dynamic stack; we're still missing the parameters for either stack): > > I'm not claiming that +RTS -xc in its present form is what you want. > I'm interested in finding an underlying mechanism that allows the right > information to be obtained; things like source locations and free > variables are just decoration. And I'm saying that adding mapException annotations is a way to get there, with very little extra effort (just the get-the-source-location part of the finding-the-needle transformation would be sufficient). > Now, most of the existing methods have problems with CAFs. I > doubt that the problems with CAFs are fixable using the source-to-source > transformation methods, but I think they might be fixable using > cost-centre stacks. One of the nice things about my suggestion to mix an "annotate with mapException" transformation with cost-centre stacks is that it would cover CAFs as well. As another example, I tried the nofib-buggy:anna test case discussed at http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack/StackTraceExperience which does have just such a CAF problem (the error is caused in a local CAF, and raised in a standard library CAF), amongst other nasty features (no CPP/sed only transformation will handle infix applications, the initial error message doesn't even tell us where to start annotating). Starting from the cost-centre approach (which fails on this example), I proceeded as follows: - the initial error is "Main: divide by zero" - this doesn't tell us where the issue is, so we have to annotate all calls to 'div', which we do by wrapping in 'mapException', adding some location information to any exceptions raised (*) - the changes are $ darcs wh hunk ./real/anna/SmallerLattice.hs 229 - = let diff = ((n2 * 10) `div` n1) - scaleup_ratio - scaleFact = n2 `div` 10 + = let diff = mapError "local_cost:diff" $ ((n2 * 10) `div` n1) - scaleup_ratio + scaleFact = mapError "local_cost:scaleFact" $ n2 `div` 10 hunk ./real/anna/Utils.hs 38 +import Control.Exception hunk ./real/anna/Utils.hs 105 - = let k = s1 `div` 53668 + = let k = mapError "rands:k" $ s1 `div` 53668 hunk ./real/anna/Utils.hs 109 - k' = s2 `div` (s1' - s1') + k' = mapError "rands:k'" $ s2 `div` (s1' - s1') hunk ./real/anna/Utils.hs 635 + +mapError src = mapException (\(SomeException e)->ErrorCall $ show e++"\n"++src) +errorSrc src = error . (++"\n"++src) - I added these annotations by hand - any automated transformation could easily be more precise about the source location messages - output of annotated version (reformatted, as for the others on that page): Main.exe: divide by zero rands:k' This appears to be in the same ballpark as what the more complex transformations (hat, finding-the-needle) deliver. Claus (*) I took a shortcut here, by mapping all exceptions to 'ErrorCalls'; if the original code contained exception handlers, one would have to be more careful, generically extending all exceptions without changing their types; but this has to be done only once, and the extended 'mapError' would go into the standard debug libraries. From marlowsd at gmail.com Sun Jun 7 10:32:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Sun Jun 7 10:16:32 2009 Subject: Should exhaustiveness testing be on by default? In-Reply-To: <6F3C5B3D1F8B4315B7277B88E747BB62@cr3lt> References: <20090517235341.GD13246@whirlpool.galois.com><404396ef0905180138y21fcaa56q3d5c2667cfb8d016@mail.gmail.com><4A140DA8.4030705@gmail.com><316F3313346D4C0C9A70F220FB26DED3@cr3lt> <20090523000511.GA3344@sliver.repetae.net><2CFB78D46A6144BFB5DADD9AF85C7CC8@cr3lt><4A1E7069.7010500@gmail.com><162772D134DA46E586DAB142369ECFE5@cr3lt> <4A25094E.7020609@gmail.com> <6F3C5B3D1F8B4315B7277B88E747BB62@cr3lt> Message-ID: <4A2BCF96.8000200@gmail.com> Claus Reinke wrote: > Perhaps I've been misunderstanding what you mean by "lexical stack"? > "lexical" to me implies only scope information, nothing related to run > time call chains, which would be "dynamic". In the "dynamic" case, one > can then distinguish between call-by-need stack (what actually happens > in GHC) and call-by-value stack (pretend that everything is strict). Ah, ok. Terminology mismatch. My "lexical call stack" and your "pseudo-cbv" are almost the same thing, I think. The way a cost-centre stack is built is described in the docs: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#prof-rules > What the cost-centre stack delivers appears to be more than scopes, > and less than a full static call graph (which would have to include non > deterministic branches, since the actual choice of branches depends on > runtime information) - it seems to use runtime information to give a > slice of the full call graph (eg, not all call sites that could call the > current function, but only the one that did so in the current run)? I'm not sure what you mean here. e.g. "non-deterministic branches"? Obviously the shape of the call stack depends upon values at runtime. >>> Here are the +RTS -xc and mapException outputs together (.. >>> - they seem to complement each other (-xc has no locations, but names >>> for the lexical stack; mapError has no names, but locations for the >>> dynamic stack; we're still missing the parameters for either stack): >> >> I'm not claiming that +RTS -xc in its present form is what you want. >> I'm interested in finding an underlying mechanism that allows the >> right information to be obtained; things like source locations and >> free variables are just decoration. > > And I'm saying that adding mapException annotations is a way to get > there, with very little extra effort (just the get-the-source-location part > of the finding-the-needle transformation would be sufficient). mapException exposes information about the call-by-need stack, which is not what you want (I claim). >> Now, most of the existing methods have problems with CAFs. I doubt >> that the problems with CAFs are fixable using the source-to-source >> transformation methods, but I think they might be fixable using >> cost-centre stacks. > > One of the nice things about my suggestion to mix an "annotate > with mapException" transformation with cost-centre stacks is that > it would cover CAFs as well. As another example, I tried the > nofib-buggy:anna test case discussed at > http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack/StackTraceExperience > > > which does have just such a CAF problem (the error is caused in a local > CAF, and raised in a standard library CAF), amongst other nasty > features (no CPP/sed only transformation will handle infix applications, > the initial error message doesn't even tell us where to start annotating). The CAF problem I'm referring to is a bit different - the goal is to get a good stack trace without affecting performance by more than a constant factor. i.e. CAFs have to be evaluated no more than once, even when doing stack tracing. This turns out to be quite hard, especially when using a source-to-source transformation. The CCS implementation currently errs on the side of not giving you much information, but without re-evaluating CAFs. Hence you get a not-very-helpful call stack. However, it wouldn't be difficult to report the call stack from the site that first evaluated the CAF. > - the initial error is "Main: divide by zero" > - this doesn't tell us where the issue is, so we have to annotate all > calls to 'div', which we do by wrapping in 'mapException', So yes, you can use mapException to get the dynamic call stack. I'm not keen on this approach though, because I think the dynamic call stack is not what you want. Also, mapExceptionn is not helpful for doing profiling or displaying the call stack at a breakpoint, and I think a general call-stack mechanism should enable both of those. Cheers, Simon From uhollerbach at gmail.com Sun Jun 7 18:04:44 2009 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Sun Jun 7 17:48:27 2009 Subject: build question: ghc 6.11.20090605 -> ghc 6.10.3? Message-ID: <65d7a7e0906071504l43d8e7bo17330539fb172e5@mail.gmail.com> Hi, all, is it expected that a snapshot version (I'm using 2009.06.05) should be able to build the released version 6.10.3? This weekend I tried the "porting to an unsupported machine" procedure with the aforementioned snapshot version; that worked, after some fussing, and I seem to have a working ghc install, including several libraries and cabal. But I tried building the Haskell Platform, and it warns (rightly, as it turns out) about this being an unsupported version of ghc. So I'd like to get onto the regular release train, as it were, and transfer myself to ghc 6.10.3. But that fails to build, after a while. Specifically, it goes until it's trying to compile the stage1 version of ghc/Main.hs, and then it complains that it can't find the file "../includes/ghcautoconf.h". Now, that file does exist; but it looks like it's being referenced from HsVersions.h, which lives in the lib/ tree of the installed snapshot compiler, and relative to the location of that file, there is indeed no such path. Is that a bug? If I create the includes directory where HsVersions.h appears to be seeking it, and add in ghcautoconf.h from where it got created during the setup of ghc 6.10.3, the build proceeds (a little) further, but it still dies. thanks... Uwe PS I suppose I should describe in a little bit of detail what I did for the porting, might be useful for someone else trying this. It was a rather vanilla port, x86_64-unknown-linux to same; my target machine is my workstation at work, where I don't have root, and I do have permission from IT to install this stuff, but no support... so they won't install rpms for me, or anything like that. It's also a slightly old and somewhat customized version of some RedHat corporate release, so recent plain-vanilla tarballs didn't work... hence the need to port. So: first problem was that my target machine identified itself as x86_64-unknown-linux-gnu; note the 4-part identifier, rather than the 3-part that's more usual. That confused the configure scripts... I had to hack up configure.ac to force it to see itself as x86_64-unknown-linux. First problem solved... After that, the back-and-forth of the various derived files was tedious but straightforward, and stuff built well. The second problem was that the command listed on the ghc porting page, "for c in libraries/*/configure; ...", is specific to bash or sh, and my workstation runs tcsh. No problem, I knew what to do, but it might be an issue for someone who doesn't know. The third issue was the sed syntax on the same page: the version of sed that I was using didn't like the space between the "-i" and the ".bak". I don't know if that's a variation from one version of sed to another, or a typo on the page, or??? Again no big deal, the error message from sed was informative enough for me to figure out what to do. The fourth issue was that the "make all_ghc_stage2" command failed: the linker complained that it couldn't find the hs_main symbol. I found that in RtsMain.o, and manually added that object file to the appropriate (?) library; then it worked. I'm not actually sure that I got the actually-most-correct library, but... it didn't seem to break anything. After that, it went through ok. I checked that that stage2 compiler could indeed build a working executable from haskell sources, that was ok, and then I rebuilt that snapshot from scratch using that compiler. That worked fine, and after that the various libraries needed to get cabal up and running were straightforward. From Christian.Maeder at dfki.de Mon Jun 8 05:16:13 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jun 8 04:59:58 2009 Subject: 6.10.4 plans In-Reply-To: <20090520233820.GA27413@matrix.chaos.earth.li> References: <20090520233820.GA27413@matrix.chaos.earth.li> Message-ID: <4A2CD6DD.3000201@dfki.de> When building ghc-6.10.3 I've noticed again: 1. ghc-pkg check: There are problems in package rts-1.0: include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory after "make binary-dist" I'm left with an unnecessary .tar file and a link (ghc-6.10.3 -> .). The mere *.tar.bz2 file would do (and is big enough). Cheers Christian Ian Lynagh wrote: > 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 From Christian.Maeder at dfki.de Mon Jun 8 06:33:25 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jun 8 06:17:09 2009 Subject: is the library iconv necessary for haskeline? In-Reply-To: <4A28DC6B.9030809@dfki.de> References: <4A28DC6B.9030809@dfki.de> Message-ID: <4A2CE8F5.1010509@dfki.de> Christian Maeder wrote: > Hi, > > building ghc-6.10.3 under x86 solaris eventually failed with: [...] > 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.bz2 > and I was able to install > http://hackage.haskell.org/packages/archive/haskeline/0.6.1.6/haskeline-0.6.1.6.tar.gz > 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. The actual cause is an evil /usr/local/include/iconv.h file that is found first and cannot be easily excluded. But passing the option "-isystem /usr/include" to gcc or setting export C_INCLUDE_PATH=/usr/include makes the haskeline installation not use "-liconv". Cheers Christian From marlowsd at gmail.com Tue Jun 9 04:50:31 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 9 04:34:13 2009 Subject: 6.10.4 plans In-Reply-To: <4A2CD6DD.3000201@dfki.de> References: <20090520233820.GA27413@matrix.chaos.earth.li> <4A2CD6DD.3000201@dfki.de> Message-ID: <4A2E2257.7000709@gmail.com> On 08/06/2009 10:16, Christian Maeder wrote: > When building ghc-6.10.3 I've noticed again: > > 1. ghc-pkg check: > > There are problems in package rts-1.0: > include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory Ian, could you merge this patch please? Thu Apr 2 11:55:40 BST 2009 Simon Marlow * PACKAGE_CPP_OPTS += -DPAPI_INCLUDE_DIR="" Thanks! > after "make binary-dist" I'm left with an unnecessary .tar file and a > link (ghc-6.10.3 -> .). The mere *.tar.bz2 file would do (and is big > enough). I fixed that in the new build system, not sure whether it's worth fixing in the branch at this stage. Cheers, Simon > Cheers Christian > > Ian Lynagh wrote: >> 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From v.reshetnikov at gmail.com Tue Jun 9 08:48:23 2009 From: v.reshetnikov at gmail.com (Vladimir Reshetnikov) Date: Tue Jun 9 08:32:03 2009 Subject: Fwd: Unification for rank-N types In-Reply-To: <4770d2590906090451p54c1359evbebfe7814ca39ceb@mail.gmail.com> References: <4770d2590906090254lce74a8endc05f2d69b33004d@mail.gmail.com> <4770d2590906090451p54c1359evbebfe7814ca39ceb@mail.gmail.com> Message-ID: <4770d2590906090548u727132d0rbbbe75afa950e838@mail.gmail.com> Forwarding to GH list. ---------- Forwarded message ---------- From: Vladimir Reshetnikov Date: Tue, 9 Jun 2009 16:51:59 +0500 Subject: Re: Unification for rank-N types To: haskell-cafe One more example: This does not type-check: ------------------------------------------------------- {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} f :: [forall a. t a -> t a] -> t b -> t b f = foldr (.) id ------------------------------------------------------- Couldn't match expected type `forall a. f a -> f a' against inferred type `b -> c' In the first argument of `foldr', namely `(.)' But this, very similar, does type-check: ------------------------------------------------------- {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} f :: [forall a. t a -> t a] -> t b -> t b f = foldr (\g -> (.) g) id ------------------------------------------------------- What is the reason for this? Thanks, Vladimir On 6/9/09, Vladimir Reshetnikov wrote: > Hi, > > I have the following code: > ------------------------------------------------------- > {-# LANGUAGE RankNTypes #-} > > f :: ((forall a. a -> a) -> b) -> b > f x = x id > > g :: (forall c. Eq c => [c] -> [c]) -> ([Bool],[Int]) > g y = (y [True], y [1]) > > h :: ([Bool],[Int]) > h = f g > ------------------------------------------------------- > > GHC rejects it: > Couldn't match expected type `forall a. a -> a' > against inferred type `forall c. (Eq c) => [c] -> [c]' > Expected type: forall a. a -> a > Inferred type: forall c. (Eq c) => [c] -> [c] > In the first argument of `f', namely `g' > In the expression: f g > > But, intuitively, this code is type-safe, and actually I can convince > the typechecker in it with the following workaround: > ------------------------------------------------------- > h :: ([Bool],[Int]) > h = let g' = (\(x :: forall a. a -> a) -> g x) in f g' > ------------------------------------------------------- > > So, is the current behavior of GHC correct ot it is a bug? > How unification for rank-N types should proceed? > > Thanks, > Vladimir > From igloo at earth.li Tue Jun 9 16:33:51 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 9 16:17:30 2009 Subject: 6.10.4 plans In-Reply-To: <4A2E2257.7000709@gmail.com> References: <20090520233820.GA27413@matrix.chaos.earth.li> <4A2CD6DD.3000201@dfki.de> <4A2E2257.7000709@gmail.com> Message-ID: <20090609203351.GA5329@matrix.chaos.earth.li> On Tue, Jun 09, 2009 at 09:50:31AM +0100, Simon Marlow wrote: > On 08/06/2009 10:16, Christian Maeder wrote: >> When building ghc-6.10.3 I've noticed again: >> >> 1. ghc-pkg check: >> >> There are problems in package rts-1.0: >> include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory > > Ian, could you merge this patch please? > > Thu Apr 2 11:55:40 BST 2009 Simon Marlow > * PACKAGE_CPP_OPTS += -DPAPI_INCLUDE_DIR="" Done! Thanks Ian From niklas.broberg at gmail.com Tue Jun 9 17:49:36 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Jun 9 17:33:16 2009 Subject: FlexibleContexts and FlexibleInstances Message-ID: 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-extensions.html#flexible-contexts [2] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-rules From claus.reinke at talk21.com Wed Jun 10 10:43:45 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jun 10 10:27:33 2009 Subject: FlexibleContexts and FlexibleInstances References: Message-ID: just a few comments from a user (who would really, really, like to be able to define pragma collections, so that he doesn't have to switch on half a dozen separate extensions every time;-). > 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. Only MultiParamTypeClasses does (and neither extension is needed in the module defining 'f', if 'T' is imported, which suggests that MultiParamTypeClasses is propagated to importers - this isn't true for most other extensions). The documentation still points to -fglasgow-exts, so it doesn't seem to answer these questions.. >> 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. You mean FlexibleContexts. > But the question is, is this a syntactic issue or a typing issue? FlexibleContexts has both syntax and static semantics implications. > Now, FlexibleInstances *also* lifts the restriction on contexts, just > like FlexibleContexts - but *only* for the contexts of instance > declarations. No. FlexibleInstances is about instance *heads*, FlexibleContexts is about contexts everywhere (in practice, there are some bugs;-). class T a b -- requires MultiParamTypeClasses instance T a a -- requires FlexibleInstances instance Eq () => T a [b] -- requires FlexibleContexts instance Eq [a] => T a b -- requires UndecidableInstances (if you actually wanted to use 'T's methods, you'd then need OverlappingInstances, but that, UndecidableInstances, and the static semantics aspects of FlexibleContexts are beyond parsing) I also seem to recall more dependencies between flags than I can find documented. Hth, Claus From niklas.broberg at gmail.com Wed Jun 10 20:29:18 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 10 20:12:53 2009 Subject: FlexibleContexts and FlexibleInstances In-Reply-To: References: Message-ID: Hi Claus, What you describe is exactly how I would *want* things to work. It's nice to hear my wishes echoed from a user perspective. :-) On Wed, Jun 10, 2009 at 4:43 PM, Claus Reinke wrote: > just a few comments from a user (who would really, really, like to be > able to define pragma collections, so that he doesn't have to switch > on half a dozen separate extensions every time;-). > >> 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. > > Only MultiParamTypeClasses does (and neither extension is needed in the > module defining 'f', if 'T' is imported, which suggests that > MultiParamTypeClasses is propagated to importers - this isn't true for > most other extensions). The documentation still points to -fglasgow-exts, so > it doesn't seem to answer these questions.. Right you are - which seems very strange to me. GHC accepts the module defining 'f' with no flags at all, even though it is clearly not Haskell 98. I'd go so far as to say that's a bug (as opposed to just unwanted/unexpected behavior). >>> 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. > > You mean FlexibleContexts. Indeed I do. >> Now, FlexibleInstances *also* lifts the restriction on contexts, just >> like FlexibleContexts - but *only* for the contexts of instance >> declarations. > > No. FlexibleInstances is about instance *heads*, FlexibleContexts is about > contexts everywhere (in practice, there are some bugs;-). Right, this is exactly what I *want* should happen, both as a user and as an implementor, but that's not how GHC does it. FlexibleInstances do enable FlexibleContexts for contexts in instance declarations - which I think is a wart. > ? class T a b -- requires MultiParamTypeClasses ? instance T a a -- requires > FlexibleInstances ? instance Eq () => T a [b] -- requires FlexibleContexts > instance Eq [a] => T a b -- requires UndecidableInstances Agreed - but here you avoid the tricky cases like my 'f' above. ;-) What I would want, and what I believe you want as well, is the following: ======================================== ** MultiParamTypeClasses: Enables more than one parameter in class declarations, instance heads and more than one argument to class assertions in contexts everywhere. Formally, it would mean the following changes to the Haskell 98 syntax: topdecl -> class [scontext =>] tycls tyvar1 ... tyvarn [where cdecls] (n >=1) | instance [scontext =>] qtycls inst1 ... instn [where idecls] (n >=1) context -> class | ( class1 , ... , classn ) (n>=0) class -> qtycls cls1 ... clsn (n>=1) cls -> tyvar | ( tyvar atype1 ... atypen ) (n>=1) scontext -> simpleclass | ( simpleclass1 , ... , simpleclassn ) (n>=0) simpleclass -> qtycls scls1 ... sclsn (n>=1) scls -> tyvar ** FlexibleContexts: Enables the use of non-tyvar (or tyvar applied to types) arguments to class assertions in contexts everywhere (orthogonal to whether there can be several arguments or just one). Formally it means the following syntactic changes to Haskell 98: fcontext -> fclass | ( fclass1 , ... , fclassn ) (n>=0) fclass -> qtycls atype1 ... atypen (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 for the single-argument case. (Note that I wrote type in my proposal in the OP, but it should of course be atype.) ** FlexibleInstances: Enables the use of arguments other than type constructors (possibly applied to tyvars) in instances *heads* (orthogonal to whether there can be one or more arguments, and what the context may look like). Formally it means the following syntactic changes to Haskell 98: topdecl -> instance [scontext =>] qtycls inst [where idecls] inst -> atype for the single-parameter standard-context case. (Note again that it should be atype and not type as I wrote in the OP.) ======================================== This of course only touches the syntactic part. It doesn't attempt to track things like 'instance (T a a) => R a b' that would be enabled by FlexibleContexts, nor does it attempt to track things like the Paterson conditions, but the syntax is all I'm interested in at the moment. This is the stance I will use for haskell-src-exts, unless someone protests wildly. If there is any interest, I can also propose these cases as bug reports to GHC. I hesitate to make formal proposals (e.g. for Haskell') regarding these extensions since I'm not sure I have the full story regarding the non-syntactic parts. But if there is a particular interest in that then I might go the extra mile there too. Cheers, /Niklas From claus.reinke at talk21.com Thu Jun 11 04:16:33 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jun 11 04:00:17 2009 Subject: [Haskell-cafe] Re: FlexibleContexts and FlexibleInstances References: Message-ID: <2A8EE288A60A44D59F8719BF69BE7AAD@cr3lt> |What you describe is exactly how I would *want* things to work. It's |nice to hear my wishes echoed from a user perspective. :-) actually, I was describing how things seem to work right now. |> Only MultiParamTypeClasses does (and neither extension is needed in the |> module defining 'f', if 'T' is imported, which suggests that |> MultiParamTypeClasses is propagated to importers - this isn't true for |> most other extensions). The documentation still points to -fglasgow-exts, so |> it doesn't seem to answer these questions.. | |Right you are - which seems very strange to me. GHC accepts the module |defining 'f' with no flags at all, even though it is clearly not |Haskell 98. I'd go so far as to say that's a bug (as opposed to just |unwanted/unexpected behavior). It is not that strange, really (it ought to be documented, but the fan- out from glasgow-exts/hugs mode to more detailed extensions has been fairly recent, compared to the lifetime of these features): if module 'A' exports multiparameter type classes, importers of those classes have to have MultiParamTypeClasses on - there are no legal uses of those imports otherwise (while FlexibleInstances/Contexts can just affect a subset of use sites). |> No. FlexibleInstances is about instance *heads*, FlexibleContexts is about |> contexts everywhere (in practice, there are some bugs;-). | |Right, this is exactly what I *want* should happen, both as a user and |as an implementor, but that's not how GHC does it. FlexibleInstances |do enable FlexibleContexts for contexts in instance declarations - |which I think is a wart. | |> class T a b -- requires MultiParamTypeClasses instance T a a -- requires |> FlexibleInstances instance Eq () => T a [b] -- requires FlexibleContexts |> instance Eq [a] => T a b -- requires UndecidableInstances Perhaps I should have been more explicit, but if you try that example by adding one line after the other, starting from zero extensions, you'll find that FlexibleInstances does not enable FlexibleContexts (at least not in my versions of GHC, which always stop at the first class of language errors and force me into an iterative cycle of code, error, add one pragma, error, add another pragma, ..). Claus From ml at isaac.cedarswampstudios.org Thu Jun 11 09:53:00 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Thu Jun 11 09:36:40 2009 Subject: [Haskell-cafe] Re: FlexibleContexts and FlexibleInstances In-Reply-To: <2A8EE288A60A44D59F8719BF69BE7AAD@cr3lt> References: <2A8EE288A60A44D59F8719BF69BE7AAD@cr3lt> Message-ID: <4A310C3C.4020603@isaac.cedarswampstudios.org> Claus Reinke wrote: > if module 'A' exports multiparameter type classes, importers of those > classes have to have MultiParamTypeClasses on - there are no legal > uses of those imports otherwise (while FlexibleInstances/Contexts can > just affect a subset of use sites). say we have module A where { class Coerce a b where coerce :: a -> b } module B where { import A ; co a = coerce a } Syntactically, module B doesn't require MultiParamTypeClasses because the signature that's involved is only discovered during type inference. Something to beware of if those restrictions need to be implemented somehow in GHC. Niklas Broberg wrote: > If there is any interest, I can also propose these cases as bug reports to GHC. please do! -Isaac From ml at isaac.cedarswampstudios.org Thu Jun 11 10:08:26 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Thu Jun 11 09:52:33 2009 Subject: [darcs-users] dropping GHC 6.6 support In-Reply-To: <20090611101142.GA9245@petunia.outback.escape.de> References: <20090610100740.GC29325@brighton.ac.uk> <4A2FEB00.8050308@objectsecurity.com> <20090610192143.GB26707@petunia.outback.escape.de> <20090611093424.GT26247@hermes.my.domain> <20090611101142.GA9245@petunia.outback.escape.de> Message-ID: <4A310FDA.4050109@isaac.cedarswampstudios.org> [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 From v.reshetnikov at gmail.com Thu Jun 11 11:00:41 2009 From: v.reshetnikov at gmail.com (Vladimir Reshetnikov) Date: Thu Jun 11 10:44:14 2009 Subject: List comprehensions and impredicative rank-N types Message-ID: <4770d2590906110800k770dd4d2l797cee21bfdeebb8@mail.gmail.com> 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 From dave at zednenem.com Thu Jun 11 13:44:43 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jun 11 13:28:46 2009 Subject: [Haskell-cafe] Re: FlexibleContexts and FlexibleInstances In-Reply-To: <2A8EE288A60A44D59F8719BF69BE7AAD@cr3lt> References: <2A8EE288A60A44D59F8719BF69BE7AAD@cr3lt> Message-ID: <49a77b7a0906111044k2a172880s2926c9fa8fe36d9@mail.gmail.com> On Thu, Jun 11, 2009 at 4:16 AM, Claus Reinke wrote: > |What you describe is exactly how I would *want* things to work. It's > |nice to hear my wishes echoed from a user perspective. :-) > > actually, I was describing how things seem to work right now. > > |> Only MultiParamTypeClasses does (and neither extension is needed in the > |> module defining 'f', if 'T' is imported, which suggests that > |> MultiParamTypeClasses is propagated to importers - this isn't true for > |> most other extensions). The documentation still points to -fglasgow-exts, > so > |> it doesn't seem to answer these questions.. > | > |Right you are - which seems very strange to me. GHC accepts the module > |defining 'f' with no flags at all, even though it is clearly not > |Haskell 98. I'd go so far as to say that's a bug (as opposed to just > |unwanted/unexpected behavior). > > It is not that strange, really (it ought to be documented, but the fan- > out from glasgow-exts/hugs mode to more detailed extensions has > been fairly recent, compared to the lifetime of these features): > > if module 'A' exports multiparameter type classes, importers of those > classes have to have MultiParamTypeClasses on - there are no legal > uses of those imports otherwise (while FlexibleInstances/Contexts can > just affect a subset of use sites). It's more complicated than that. If you have two modules A and B, defined like so: {-# LANGUAGE MultiParamTypeClasses #-} module A where class Foo a b where foo :: a -> b instance Foo Bool Int where foo True = 1 foo False = 0 -- module B where import A bar :: (Foo a b) => [a] -> [b] bar = map foo I can load B.hs into GHCi and call bar without problems. So the import of Foo is fine. But you still get an error if you try to declare an instance of Foo in B.hs. instance Foo Bool Integer where foo True = 1 foo False = 0 B.hs:8:0: Illegal instance declaration for `Foo Bool Integer' (Only one type can be given in an instance head. Use -XMultiParamTypeClasses if you want to allow more.) In the instance declaration for `Foo Bool Integer' Failed, modules loaded: A. -- Dave Menendez From claus.reinke at talk21.com Thu Jun 11 13:56:55 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Jun 11 13:40:33 2009 Subject: [Haskell-cafe] Re: FlexibleContexts and FlexibleInstances References: <2A8EE288A60A44D59F8719BF69BE7AAD@cr3lt> <49a77b7a0906111044k2a172880s2926c9fa8fe36d9@mail.gmail.com> Message-ID: <213B7063BD94413EB628A0B32D3D854D@cr3lt> > {-# LANGUAGE MultiParamTypeClasses #-} > module A where > class Foo a b where foo :: a -> b > > instance Foo Bool Int where > foo True = 1 > foo False = 0 > > module B where > import A > > bar :: (Foo a b) => [a] -> [b] > bar = map foo > > I can load B.hs into GHCi and call bar without problems. So the import > of Foo is fine. But you still get an error if you try to declare an > instance of Foo in B.hs. > > instance Foo Bool Integer where > foo True = 1 > foo False = 0 > > B.hs:8:0: > Illegal instance declaration for `Foo Bool Integer' > (Only one type can be given in an instance head. > Use -XMultiParamTypeClasses if you want to allow more.) > In the instance declaration for `Foo Bool Integer' > Failed, modules loaded: A. Ah, that is one definite bug waiting for a ticket, then: - inheritance of MultiParamTypeClasses is not specified - if it is inherited, the instance in B should be permitted - if it is not inherited, the context in B should not be permitted Claus From simonpj at microsoft.com Fri Jun 12 19:28:30 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jun 12 19:11:59 2009 Subject: Unification for rank-N types In-Reply-To: <4770d2590906090548u727132d0rbbbe75afa950e838@mail.gmail.com> References: <4770d2590906090254lce74a8endc05f2d69b33004d@mail.gmail.com> <4770d2590906090451p54c1359evbebfe7814ca39ceb@mail.gmail.com> <4770d2590906090548u727132d0rbbbe75afa950e838@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C337FDF071F9@EA-EXMSG-C334.europe.corp.microsoft.com> Vladimir [NB: the subject line is wrong: this email is all about impredicativity, and not at all about higher-rank types.] | This does not type-check: | {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} | f :: [forall a. t a -> t a] -> t b -> t b ... | But this, very similar, does type-check: The short answer is that impredicative polymorphism in GHC are not fully implemented. And even if it were, the specification is relatively complex. For example, it's quite possible that e and (\x. e x) don't behave the same from a typing point of view. To be honest I'm not sure whether your program fails to typecheck because of a bug in GHC, or because the specification says it shouldn't. (I'm travelling, so I can't check the spec.) I'm ccing Dimitrios who will probably know. The longer answer is this. It has slowly become clear that there are many possible design choices that allow impredicative polymorphism to be mixed with type inference; indeed two new papers were published only last year (by Dimitrios and Daan). To my mind it is still not clear what the best trade-off is; the solutions that are nicest for the programmer are really rather complicated to implement, and vice versa. I am not convinced that the design choice currently embodied in GHC is the right one -- and the implementation turned out to get tangled up with already-complex bits of the typechecker, rather than being modularly separable. So the current implementation is a mess: hard to understand, and hard to maintain. So the current situation is that - impredicative polymorphism in GHC is only partially implemented, and almost certainly has bugs - I'm quite inclined to take it out altogether, for the reasons described above - In due course I'd like to put in some simple, robust, but perhaps somewhat less convenient, way to allow impredicative polymorphism, but I'm not quite sure what form it should take Meanwhile I'd be interested to know * does anyone impredicative polymorphism in GHC (-XImpredicativeTypes)? My perception is that very few people do, but I could be wrong, and if so I should be more careful about taking it out again! Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Vladimir Reshetnikov | Sent: 09 June 2009 13:48 | To: glasgow-haskell-users@haskell.org | Subject: Fwd: Unification for rank-N types | | Forwarding to GH list. | | ---------- Forwarded message ---------- | From: Vladimir Reshetnikov | Date: Tue, 9 Jun 2009 16:51:59 +0500 | Subject: Re: Unification for rank-N types | To: haskell-cafe | | One more example: | | This does not type-check: | ------------------------------------------------------- | {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} | | f :: [forall a. t a -> t a] -> t b -> t b | f = foldr (.) id | ------------------------------------------------------- | | Couldn't match expected type `forall a. f a -> f a' | against inferred type `b -> c' | In the first argument of `foldr', namely `(.)' | | But this, very similar, does type-check: | ------------------------------------------------------- | {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} | | f :: [forall a. t a -> t a] -> t b -> t b | f = foldr (\g -> (.) g) id | ------------------------------------------------------- | | What is the reason for this? | | Thanks, | Vladimir | | | On 6/9/09, Vladimir Reshetnikov wrote: | > Hi, | > | > I have the following code: | > ------------------------------------------------------- | > {-# LANGUAGE RankNTypes #-} | > | > f :: ((forall a. a -> a) -> b) -> b | > f x = x id | > | > g :: (forall c. Eq c => [c] -> [c]) -> ([Bool],[Int]) | > g y = (y [True], y [1]) | > | > h :: ([Bool],[Int]) | > h = f g | > ------------------------------------------------------- | > | > GHC rejects it: | > Couldn't match expected type `forall a. a -> a' | > against inferred type `forall c. (Eq c) => [c] -> [c]' | > Expected type: forall a. a -> a | > Inferred type: forall c. (Eq c) => [c] -> [c] | > In the first argument of `f', namely `g' | > In the expression: f g | > | > But, intuitively, this code is type-safe, and actually I can convince | > the typechecker in it with the following workaround: | > ------------------------------------------------------- | > h :: ([Bool],[Int]) | > h = let g' = (\(x :: forall a. a -> a) -> g x) in f g' | > ------------------------------------------------------- | > | > So, is the current behavior of GHC correct ot it is a bug? | > How unification for rank-N types should proceed? | > | > Thanks, | > Vladimir | > | _______________________________________________ From coreyoconnor at gmail.com Sat Jun 13 12:21:13 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Sat Jun 13 12:04:38 2009 Subject: Help debugging a deadlock in salvia on GHC 6.10 i386 In-Reply-To: References: Message-ID: On Sat, Jun 6, 2009 at 2:09 PM, Corey O'Connor wrote: > I'm running a webserver built using salvia [1] and GHC 6.10 [2]. I've > trimmed down the code enough such that there is no obvious source of a > deadlock in either salvia or the reset of the web server. I don't have > any specific conditions that reproduce the issue as well. Just after > some time, anywhere from a few minutes to a few hours, the server > deadlocks. No particular request or number of requests seem to trigger > the deadlock. I've narrowed down the issue to be related to the use of System.Timeout.timeout. Without the use of the timeout combinator the server does not hit a deadlock condition. With the use of the combinator the server eventually deadlocks. I'll look into if any of salvia's threads would be aversely effected by a timeout. Are there any known issues with the timeout implementation besides the (reasonable) inability to timeout FFI calls? Cheers, Corey O'Connor From p.k.f.holzenspies at utwente.nl Mon Jun 15 06:09:18 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Mon Jun 15 05:52:02 2009 Subject: GADT record syntax and contexts Message-ID: <1245060558.25705.17.camel@ewi1043> Dear GHCers, Maybe this question is more for Haskell-cafe, but since it involves language extensions as provided by GHC, it seems reasonable to post it here. The GHC user guide lists under 7.4 [1] the extensions to data types and type synonyms. My question involves 7.4.5 (although the overlap with 7.4.6 is considerable; maybe the two should be merged). A property of GADTs that I really appreciate is the fact that constructor contexts are made available by pattern matching (I don't quite understand why normal ADTs could do this, btw, but that's another question). The problem I have now, though, is that there doesn't seem to be a syntax to combine contexts and records in GADTs. Consider this program: data ContTest a where A :: Show a => a -> ContTest a data RecTest a where B { arg :: a } :: RecTest a data RecContTest a where C { showable :: Show a => a } :: RecContTest a a :: ContTest a -> String a (A a) = show a b :: Show a => RecTest a -> String b = show . arg c :: RecContTest a -> String c (C { showable = x }) = show x Both ContTest and RecTest work swimmingly (with functions a and b, respectively). However, GHC complains that it can not deduce Show for type a in function c. My definition of RecContTest is the only syntactical form I could come up with that GHC accepts. Is there a syntax for what I want here? Regards, Philip PS. As a side-note. In section 7.4.5, the manual states that: "At the moment, record updates are not yet possible with GADT-style declarations, so support is limited to record construction, selection and pattern matching." However, if I add: update org@(B {}) x = org { arg = x } and evaluate "b $ update (B True) False" the response is "False" as one would expect. Is this line in the user guide outdated, or is support for updates unstable or partial? [1]http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html From marlowsd at gmail.com Mon Jun 15 07:58:55 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 15 07:42:19 2009 Subject: Help debugging a deadlock in salvia on GHC 6.10 i386 In-Reply-To: References: Message-ID: <4A36377F.4070409@gmail.com> On 13/06/2009 17:21, Corey O'Connor wrote: > On Sat, Jun 6, 2009 at 2:09 PM, Corey O'Connor wrote: >> I'm running a webserver built using salvia [1] and GHC 6.10 [2]. I've >> trimmed down the code enough such that there is no obvious source of a >> deadlock in either salvia or the reset of the web server. I don't have >> any specific conditions that reproduce the issue as well. Just after >> some time, anywhere from a few minutes to a few hours, the server >> deadlocks. No particular request or number of requests seem to trigger >> the deadlock. > > I've narrowed down the issue to be related to the use of > System.Timeout.timeout. Without the use of the timeout combinator the > server does not hit a deadlock condition. With the use of the > combinator the server eventually deadlocks. > > I'll look into if any of salvia's threads would be aversely effected > by a timeout. Are there any known issues with the timeout > implementation besides the (reasonable) inability to timeout FFI > calls? I don't know of any current issues, but historically there have been several bugs in this area. System.Timeout uses throwTo, which is devilishly difficult to get right. I assume you're using GHC 6.10.3? If you could compile your server with -debug and capture the output when running it with +RTS -Ds, that might help us diagnose the problem. Cheers, Simon From simonpj at microsoft.com Tue Jun 16 05:19:50 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 16 05:03:17 2009 Subject: GADT record syntax and contexts In-Reply-To: <1245060558.25705.17.camel@ewi1043> References: <1245060558.25705.17.camel@ewi1043> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> Philip Thanks for your msg (which appears in full below for reference.) | data RecContTest a where | C { showable :: Show a => a } :: RecContTest a This definitely isn't going to work: it declares the 'showable' field to be a function that *requires* a Show context, not one that *provides* a Show context. | type a in function c. My definition of RecContTest is the only | syntactical form I could come up with that GHC accepts. Is there a | syntax for what I want here? Not at the moment, I'm afraid. The problem is mainly to find a decent syntax -- and that problem made me simply omit it altogether. Probably the most plausible possibilities are (A) data RecContTest a where Show a => C { showable :: Show a => a } :: RecContTest a (B) data RecContTest a where C :: Show a => { showable :: Show a => a } -> RecContTest a The latter (B) looks best to me. I dislike (A) because part of the type (the "Show a =>") occurs before the constructor name C, and part appears after. On the other hand, (B) has something that looks vaguely like a type { x::ty, y::ty } -> ty but that's not really valid type syntax. (Mind you, the ! marks in a constructor signature aren't part of valid types either, so maybe it's not so bad to have a special form in constructor declarations.) But if we were going to adopt (B), then even when there is no class context we should really say (B) data RecTest a where B :: { arg :: a } -> RecTest a rather than the current syntax which is (A) data RecTest a where B { arg :: a } :: RecTest a [Note the different placement of the double colon and arrow in (B).] My take on this (B) looks nicer, but it would represent a breaking change But perhaps not many people use record-style syntax + GADT-style syntax And better to make breaking changes sooner than later Question for everyone: * are (A) and (B) the only choices? * do you agree (B) is best Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Philip K.F. H?lzenspies | Sent: 15 June 2009 11:09 | To: glasgow-haskell-users@haskell.org | Subject: GADT record syntax and contexts | | Dear GHCers, | | Maybe this question is more for Haskell-cafe, but since it involves | language extensions as provided by GHC, it seems reasonable to post it | here. | | The GHC user guide lists under 7.4 [1] the extensions to data types and | type synonyms. My question involves 7.4.5 (although the overlap with | 7.4.6 is considerable; maybe the two should be merged). A property of | GADTs that I really appreciate is the fact that constructor contexts are | made available by pattern matching (I don't quite understand why normal | ADTs could do this, btw, but that's another question). The problem I | have now, though, is that there doesn't seem to be a syntax to combine | contexts and records in GADTs. Consider this program: | | data ContTest a where | A :: Show a => a -> ContTest a | | data RecTest a where | B { arg :: a } :: RecTest a | | data RecContTest a where | C { showable :: Show a => a } :: RecContTest a | | a :: ContTest a -> String | a (A a) = show a | | b :: Show a => RecTest a -> String | b = show . arg | | c :: RecContTest a -> String | c (C { showable = x }) = show x | | Both ContTest and RecTest work swimmingly (with functions a and b, | respectively). However, GHC complains that it can not deduce Show for | type a in function c. My definition of RecContTest is the only | syntactical form I could come up with that GHC accepts. Is there a | syntax for what I want here? | | Regards, | Philip | | | | PS. As a side-note. In section 7.4.5, the manual states that: | | "At the moment, record updates are not yet possible with GADT-style | declarations, so support is limited to record construction, selection | and pattern matching." | | However, if I add: | | update org@(B {}) x = org { arg = x } | | and evaluate "b $ update (B True) False" the response is "False" as one | would expect. Is this line in the user guide outdated, or is support for | updates unstable or partial? | | | [1]http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html From simonpj at microsoft.com Tue Jun 16 05:20:39 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 16 05:04:43 2009 Subject: GADT record syntax and contexts In-Reply-To: <1245060558.25705.17.camel@ewi1043> References: <1245060558.25705.17.camel@ewi1043> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E68E@EA-EXMSG-C334.europe.corp.microsoft.com> | PS. As a side-note. In section 7.4.5, the manual states that: | | "At the moment, record updates are not yet possible with GADT-style | declarations, so support is limited to record construction, selection | and pattern matching." | | However, if I add: | | update org@(B {}) x = org { arg = x } | | and evaluate "b $ update (B True) False" the response is "False" as one | would expect. Is this line in the user guide outdated, or is support for | updates unstable or partial? Ah yes. The support is partial. The update is supported if it "makes sense" from a type point of view. I should write down what "makes sense" means! Simon From zunino at di.unipi.it Tue Jun 16 08:28:34 2009 From: zunino at di.unipi.it (Roberto Zunino) Date: Tue Jun 16 08:11:53 2009 Subject: GADT record syntax and contexts In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1245060558.25705.17.camel@ewi1043> <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4A378FF2.70900@di.unipi.it> Simon Peyton-Jones wrote: > (A) data RecContTest a where > Show a => C { showable :: Show a => a } :: RecContTest a > > (B) data RecContTest a where > C :: Show a => { showable :: Show a => a } -> RecContTest a What about (A') data RecContTest a where Show a => C { showable :: a } :: RecContTest a (B') data RecContTest a where C :: Show a => { showable :: a } -> RecContTest a ? Would this be allowed? I would expect A' and B' to generate showable :: RecContTest a -> a and not the less useful (Show-requiring) showable :: Show a => RecContTest a -> a Zun. From p.k.f.holzenspies at utwente.nl Tue Jun 16 08:45:10 2009 From: p.k.f.holzenspies at utwente.nl (=?ISO-8859-1?Q?Philip_H=F6lzenspies?=) Date: Tue Jun 16 08:28:32 2009 Subject: GADT record syntax and contexts In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1245060558.25705.17.camel@ewi1043> <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1E200A11-CBE3-4143-A6C3-6D759EBD4845@utwente.nl> Dear Simon and fellow GHCers, Thank you for having a look at this. I've inlined my response with your message. > | data RecContTest a where > | C { showable :: Show a => a } :: RecContTest a > > This definitely isn't going to work: it declares the 'showable' > field to be a function that *requires* a Show context, not one that > *provides* a Show context. Absolutely. Like I said, I committed the sin of hacking until GHC stopped complaining. At some point, I turned off the semantics in my head ;) > The problem is mainly to find a decent syntax -- and that problem > made me simply omit it altogether. Probably the most plausible > possibilities are > > (A) data RecContTest a where > Show a => C { showable :: Show a => a } :: RecContTest a > > (B) data RecContTest a where > C :: Show a => { showable :: Show a => a } -> RecContTest a I presume there's a little copy-paste mishap going on here and that you mean: (A) data RecContTest a where Show a => C { showable :: a } :: RecContTest a (B) data RecContTest a where C :: Show a => { showable :: a } -> RecContTest a > The latter (B) looks best to me. I dislike (A) because part of the > type (the "Show a =>") occurs before the constructor name C, and > part appears after. On the other hand, (B) has something that looks > vaguely like a type > { x::ty, y::ty } -> ty > but that's not really valid type syntax. (Mind you, the ! marks in > a constructor signature aren't part of valid types either, so maybe > it's not so bad to have a special form in constructor declarations.) I'm afraid I'm not too well informed with regards to type syntax, but another reason to prefer B over A is that it looks much more like a normal function declaration. When I explain GADTs and their syntax to people that haven't used them before, I usually start off by saying that constructors are simply functions. With GADTs, the declarations of the constructors look exactly like those of functions, but you don't have to worry about providing a binding. > But if we were going to adopt (B), then even when there is no class > context we should really say > > (B) data RecTest a where > B :: { arg :: a } -> RecTest a > > rather than the current syntax which is > > (A) data RecTest a where > B { arg :: a } :: RecTest a > > [Note the different placement of the double colon and arrow in (B).] Again, B is much more in-sync with "normal GADTs" (i.e. non-record syntax) and with the perspective of constructors-as-functions I mentioned above. The record parts of B don't seem to be function-like, but it is how I would define functions on extensible records (regardless of the current status of different implementations / alternatives). To me, this foo :: { bar :: Bool, tutu :: Int } -> String means that foo is a function on any record that contains at least the fields bar and tutu of the mentioned types. > My take on this > (B) looks nicer, but it would represent a breaking change > But perhaps not many people use record-style syntax + GADT-style > syntax > And better to make breaking changes sooner than later One very important reason for me to use GADTs nowadays, is that they provide contexts in pattern matches. If normal ADTs were to do the same, I would use far less GADTs. Record syntax just makes sense when you stick more than three arguments in a constructor. Having said that, *every* ADT seems to be a record in GHC: data FooBar = Foo Int Int | Bar Char isFoo Foo {} = True isFoo _ = False Rounding up; B has my strong preference over A. I don't know whether very strong alternatives will present themselves, but B seems quite nice in general. Regards, Philip From g9ks157k at acme.softbase.org Tue Jun 16 08:49:32 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Jun 16 08:32:50 2009 Subject: [grapefruit] can't run Grapefruit In-Reply-To: References: Message-ID: <200906161449.33194.g9ks157k@acme.softbase.org> Am Samstag, 23. Mai 2009 21:58 schrieb Dean Herington: > I'm trying to give Grapefruit a try. I installed it as described in > section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I > tried to run the Simple.hs example, I got the problem shown below. > Any ideas? > > My machine is running Windows XP Pro 2002 SP3. > > TIA > Dean Hello Dean, were you able to solve this problem meanwhile? Since this seems to be a Gtk2Hs problem and I don?t use Windows, I probably cannot be of much help. :-( Best wishes, Wolfgang From ml at isaac.cedarswampstudios.org Tue Jun 16 12:13:01 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Jun 16 11:56:26 2009 Subject: GADT record syntax and contexts In-Reply-To: <1E200A11-CBE3-4143-A6C3-6D759EBD4845@utwente.nl> References: <1245060558.25705.17.camel@ewi1043> <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> <1E200A11-CBE3-4143-A6C3-6D759EBD4845@utwente.nl> Message-ID: <4A37C48D.1010306@isaac.cedarswampstudios.org> Philip H?lzenspies wrote: > (A) data RecContTest a where > Show a => C { showable :: a } :: RecContTest a > > (B) data RecContTest a where > C :: Show a => { showable :: a } -> RecContTest a I like (B) better too, for any GADT record syntax... its meaning seems less confusing to me than the current(?) (A) syntax. -Isaac From phercek at gmail.com Wed Jun 17 05:14:39 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed Jun 17 04:58:12 2009 Subject: better generation of vi ctags in ghci Message-ID: 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. From jwlato at gmail.com Wed Jun 17 06:48:35 2009 From: jwlato at gmail.com (John Lato) Date: Wed Jun 17 06:31:49 2009 Subject: GADT record syntax and contexts Message-ID: <9979e72e0906170348t75815a16p979925fb0c65fc0d@mail.gmail.com> >From the perspective of someone who doesn't use GADT's much, I find (B) to be more clear. John Lato > SPJ wrote: > > Question for everyone: > > ?* are (A) and (B) the only choices? > ?* do you agree (B) is best > From claus.reinke at talk21.com Wed Jun 17 07:02:26 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jun 17 06:45:48 2009 Subject: better generation of vi ctags in ghci References: Message-ID: > 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 I'm all in favour of ctags improvements in general! Thanks for investing the effort. Haven't looked at your patch in detail yet, just a few comments based on your message: > 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). Haskell isn't like other languages. If you search on source lines of definitions, that'll break every time you change a pattern, parameter name, parameter order, clause order, ..; if you search on less than the full line, you get additional misleading matches, especially because you can only search forward or backward, not both (also, the fallback of /^/ won't work for infix operators, classes, data, ..). Ideally, one (well, I at least;-) would like a mixed approach: start with source line, figure out if the line is right, if yes, done, if not, then search (starting from the old position). But that seemed to be beyond posix tags, so I stuck with line numbers. If the definition you're looking for isn't close to where it was, you'd better regenerate the tags anyway; if the definition is still close, line numbers degrade gracefully; search patterns tend to break completely (on the other hand, line number changes affect more tags than definition changes do, so it would be useful to have both options). Note that emacs always does a search, but it does search outwards in both directions, from the old location as the start position, so it can make do with an underspecified search pattern, such as the tag itself (if I recall correctly, the etags position might be off by one anyway; emacs doesn't have lines/columns, it counts bytes from the start or something like that, which meant that the etags and ctags parts couldn't share all their code). > * 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. Thanks, I had meant to do this, don't know why I didn't (you use the new static tag format, not the old, I assume?). > * 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). You mean 'kind' in the tags file sense, using it to record namespace, similar to haddock's t/v distinction? The extended tag line format is somewhat underspecified (only file: and kind: are mentioned in Vim's docs), so I could not make up my mind what to use kind: for (namespace? type? kind? type/data/class? package? ..) and I couldn't figure out whether any editors would actually use the extra info if I were to add extra fields to add all the useful info. In Vim, that info could be accessed via scripts, so it would be useful to add all of it, but some standard would help; also some of the info that :ctags could record in the tags file can be had by other means, including :type and :info output, and those other means will often be more up to date than the tags file, so I added no extra info to the tags file. > * 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. That's why I suggested the addition in the first place!-) Thanks for taking it further. The one real show-stopper are files that GHCi can't handle: because the ctags/etags patch borrowed all the interesting functionality from GHCi, it inherited its limitations as well (there is a ghctags program somewhere which circumvents that issue by not trying to generate code when generating tags, so it can handle tags for GHC's sources, which GHCi :ctags couldn't, last time I tried). A secondary issue was what to do with non-interpreted modules (probably: just skip, and rely on them having their own tags files). (btw, I also use '_si' more since I switched it to open a preview window for the :info output, and of course, one can get the types without having to record them in the tags file). > 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). I'm not an emacs user, either, I just added both versions because I saw no reason not to (and I had been looking into the curious world of emacs terminology for other reasons). Simon M did quite a bit of cleanup on my original patch, if I recall, perhaps other emacs users care to take a look? > * 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. See above for other things that can go wrong with search-based tags, so I'd prefer to have both options. Claus From phercek at gmail.com Wed Jun 17 07:59:24 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed Jun 17 07:42:58 2009 Subject: better generation of vi ctags in ghci In-Reply-To: References: Message-ID: <4A38DA9C.9000505@gmail.com> Claus Reinke wrote: > Haskell isn't like other languages. If you search on source lines of > definitions, that'll break every time you change a pattern, parameter > name, parameter order, clause order, .. This is what I do. The whole line is searched to avoid as much of false positives as possible. So far I did not get any false positive in my code with this approach. > ; if you search on less than the full line, you get additional > misleading matches, especially because you > can only search forward or backward, not both (also, the fallback of > /^/ won't work for infix operators, classes, data, ..). > > Ideally, one (well, I at least;-) would like a mixed approach: start with > source line, figure out if the line is right, if yes, done, if not, > then search > (starting from the old position). But that seemed to be beyond posix > tags, so I stuck with line numbers. I tried some form of that (set position before the expected loction before searching). It could be done better but then the tag file would get big (inline all the code for each tag, or we would need some functions defined outside of the tags file). Anyway the reason I dropped this was that my vim did not parse this file correctly and tag kinds (as defined in the vim tags file) were not shown in the :tselect list. So I decided it is not worth it for now. It would be cool to have something better but I do not know whether it is possible aside from just writing an interactive compiler (something like yi people are trying - I do not know how far did they get). >> * 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. > > Thanks, I had meant to do this, don't know why I didn't (you use the new > static tag format, not the old, I assume?). I use the latest format: {tagname} {TAB} {tagfile} {TAB} {tagaddress} {term} {field} .. Where {tagaddress} is a search expression looking for whole lines. >> * 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). > > You mean 'kind' in the tags file sense, using it to record namespace, > similar to haddock's t/v distinction? I mean kind in the tags file sense. I do not know about haddock's t/v distinction so I cannot compare to it. So far I use: * v (varId), * t (typeCon), * d (dataCon), * c (class). >> * 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. > > That's why I suggested the addition in the first place!-) Thanks for > taking it further. NP, it is great! I did not know there is at least one more person wanting better tags. I did not even know about ghctags. Otherwise I would probably just use them if they are any good (generate non-exported symbols too and use search patterns instead of the line numbers ... so they are at least a bit useful after some edits). Ok, the reason I care about tags to be useful after some edits is that for some of my files it takes some time to compile them in ghci. And I don't want to think about regenerating them regularly. Now I need to regenerate them only when the tag cannot be located or it found an incorrect place (which did not happen to me yet). > for GHC's sources, which GHCi :ctags couldn't, last time I tried). A > secondary issue was what to do with non-interpreted modules > (probably: just skip, and rely on them having their own tags files). Skipping is fine with me. >> * 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. > > See above for other things that can go wrong with search-based tags, > so I'd prefer to have both options. Ok, I can add it. Generating line numbers instead of search patterns will be quicker too. For big projects, the time difference may be noticeable. So what about UI? :ctags would generate tags with line numbers and :ctags! would generate tags with search patterns? Or will we add an argument to :ctags to specify what kind of tags we want? This option would break ghci UI backward compatibility. Peter. From ndmitchell at gmail.com Wed Jun 17 10:11:57 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jun 17 09:55:12 2009 Subject: --out-implib when linking shared libraries In-Reply-To: References: <404396ef0905150731se9b4d08i4946dafa0f1217c3@mail.gmail.com> <1242408866.29736.184.camel@localhost> <404396ef0905160307q5012a267xd56cb5e76b9f470f@mail.gmail.com> <1242473213.20960.3.camel@localhost> Message-ID: <404396ef0906170711r6a7c3d25m96d4366e7e537bf2@mail.gmail.com> Hi Following up on a slightly old thread, it seems that the use of --out-implib is unnecessary for my purposes and generates 50Mb of .dll.a files. I'm also concerned that the generation of these .dll.a files may be taking considerable time (in the range of minutes). I'd like to disable the flags, using things such as -optl, but can't figure out how. The best I've come up with is: -optl=-Wl,--opt-implib=nul When doing this is generates the implib to nul, instead of to a file. That saves me 10 seconds and 50Mb of disk space, but I suspect if I could properly eliminate the opt-implib flag I'd save a significant chunk more time. Is there any way to override implib so it doesn't even try to generate it? Given Krasimir's comments, could this bug changed in a future version of GHC? Thanks, Neil On Sat, May 16, 2009 at 1:22 PM, Krasimir Angelov wrote: > I remember that the .dll.a libraries that GCC produces are not always > compatible with MSVC. Sometimes it works if you rename them to .lib > but sometimes it doesn't. It is much more realiable to create .lib > from .def file via some of the MS tools. If GCC can link dynamic > libraries without using the static library then it might be good idea > not to build the import libraries at all. > > Regards, > ?Krasimir > > > On Sat, May 16, 2009 at 1:26 PM, Duncan Coutts > wrote: >> On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote: >> >>> I don't, although having that option wouldn't be a bad thing - having >>> a minimal .lib is perfectly reasonable as a default. Having a massive >>> .lib seems crazy. (The fact that .lib is named .dll.a isn't too much >>> of an issue) >> >> It's possible to create a minimal import lib via a .def file (which >> lists the exports). I think the dlltool helps with that. >> >>> > So my suggestion is remove it, if you're linking using gcc it should >>> > work. >>> >>> I'm not linking the .dll at all, only using dynamic linking, which >>> works without the .lib. But I don't really want to start removing >>> files - doing that in a build system seems like a bad idea. >> >> Sure, so at least you don't have to install them. >> >> Duncan >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > From duncan.coutts at worc.ox.ac.uk Wed Jun 17 05:24:48 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 17 18:51:00 2009 Subject: Three patches for cabal In-Reply-To: References: Message-ID: <1245230688.13502.2939.camel@localhost> On Wed, 2009-06-03 at 16:41 +0200, Niklas Broberg wrote: > 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. Can someone please comment on these two proposed changes. I agree with Niklas but I'm a bit reluctant to apply the patches without at least some sign of agreement from someone else. Deprecating PatternSignatures seems uncontroversial, but the NoMonoPatBinds is potentially controversial. GHC essentially uses -XMonoPatBinds by default, even in H98 mode, and the user can use -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that the list of language extensions in Language.Haskell.Exceptions are differences from H98 so it should be MonoPatBinds to get the difference not NoMonoPatBinds to restore H98. In practise, since ghc uses MonoPatBinds by default it'd mean that people who want to get back to H98 would need to use: ghc-options: -XNoMonoPatBinds Because the extensions field is additive, not subtractive. Using the name MonoPatBinds allows other compilers to implement it without it having to be the default. Duncan From ganesh.sittampalam at credit-suisse.com Thu Jun 18 03:12:40 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jun 18 02:56:15 2009 Subject: Three patches for cabal In-Reply-To: <1245230688.13502.2939.camel@localhost> References: <1245230688.13502.2939.camel@localhost> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F6C8@ELON17P32001A.csfb.cs-group.com> Duncan Coutts wrote: > Niklas's and my point is > that the list of language extensions in Language.Haskell.Exceptions > are differences from H98 so it should be MonoPatBinds to get the > difference not NoMonoPatBinds to restore H98. > In practise, since ghc uses MonoPatBinds by default it'd mean that > people who want to get back to H98 would need to use: > > ghc-options: -XNoMonoPatBinds > > Because the extensions field is additive, not subtractive. Using the > name MonoPatBinds allows other compilers to implement it without it > having to be the default. In general I think there is a reasonable case for special treatment for exceptions to H98 that have been accepted for haskell-prime. However in this case the idea of having monomorphic pattern bindings has been rejected from haskell-prime, so I'm in favour of calling it 'MonoPatBinds'. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From marlowsd at gmail.com Thu Jun 18 04:37:10 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jun 18 04:20:26 2009 Subject: better generation of vi ctags in ghci In-Reply-To: References: Message-ID: <4A39FCB6.9040400@gmail.com> On 17/06/2009 10:14, Peter Hercek wrote: > 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 I'm an infrequent etags user, and I never use ctags. So while I can't give you any useful comments on your patch, if there seems to be general agreement we'll be happy to incorporate it. Cheers, Simon From jwlato at gmail.com Thu Jun 18 04:58:28 2009 From: jwlato at gmail.com (John Lato) Date: Thu Jun 18 04:41:42 2009 Subject: question about -fno-pre-inlining Message-ID: <9979e72e0906180158h54b43a0fk88e9e0fc41ba5ca6@mail.gmail.com> Hello, I was experimenting with compiler flags trying to tune some performance and got something unexpected with the -fno-pre-inlining flag. I was hoping somebody here might be able to clarify an issue for me. When compiled with -fno-pre-inlining, my test program gives a different result than compiled without (0.988... :: Double, compared to 1.0). It's numerical code, and was originally compiled with -fexcess-precision, however I have tried both with and without -fexcess-precision and the results are the same. The only other compiler flags in use are -O2 and --make. Is this expected behavior or a possible bug? I believe the value with -fno-pre-inlining is correct (and runs about 30% faster too). This was done on an OSX 10.5 Macbook with GHC-6.10.3. I could check this on some other systems if it would be helpful. Sincerely, John Lato From simonpj at microsoft.com Thu Jun 18 06:16:32 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Jun 18 05:59:54 2009 Subject: question about -fno-pre-inlining In-Reply-To: <9979e72e0906180158h54b43a0fk88e9e0fc41ba5ca6@mail.gmail.com> References: <9979e72e0906180158h54b43a0fk88e9e0fc41ba5ca6@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4B86AF58@EA-EXMSG-C334.europe.corp.microsoft.com> John | When compiled with -fno-pre-inlining, my test program gives a | different result than compiled without (0.988... :: Double, compared | to 1.0). It's numerical code, and was originally compiled with That's entirely unexpected. I am very surprised that turning off pre-inlining a) affects the results at all b) improves performance Of course this is a floating point program, where various numeric transformations are invalid if you want bit-for-bit accuracy. (eg addition is not associative). But a 2% change seems big, unless it's a very sensitive algorithm. To find out what "pre-inlining" is read Section 5 of http://research.microsoft.com/en-us/um/people/simonpj/papers/inlining/inline-jfp.ps.gz It's called "PreInlineUnconditionally" there. I'm not sure how to proceed. The more you can boil it down, the easier it'll be to find out what is going on. One way to do this is to make the program smaller. But even finding out which function is sensitive to the setting of -fno-pre-inlining would be interesting. (You can't set this on a function by function basis, so you'll have to split the module.) If you can make a self-contained test case, do make a Trac ticket for it. Are you using the FFI? All very odd. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of John Lato | Sent: 18 June 2009 09:58 | To: glasgow-haskell-users@haskell.org | Subject: question about -fno-pre-inlining | | Hello, | | I was experimenting with compiler flags trying to tune some | performance and got something unexpected with the -fno-pre-inlining | flag. I was hoping somebody here might be able to clarify an issue | for me. | | When compiled with -fno-pre-inlining, my test program gives a | different result than compiled without (0.988... :: Double, compared | to 1.0). It's numerical code, and was originally compiled with | -fexcess-precision, however I have tried both with and without | -fexcess-precision and the results are the same. The only other | compiler flags in use are -O2 and --make. Is this expected behavior | or a possible bug? I believe the value with -fno-pre-inlining is | correct (and runs about 30% faster too). | | This was done on an OSX 10.5 Macbook with GHC-6.10.3. I could check | this on some other systems if it would be helpful. | | Sincerely, | John Lato | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From phercek at gmail.com Thu Jun 18 06:33:32 2009 From: phercek at gmail.com (Peter Hercek) Date: Thu Jun 18 06:17:07 2009 Subject: ghci etags for emacs (was: better generation of vi ctags in ghci) In-Reply-To: <4A39FCB6.9040400@gmail.com> References: <4A39FCB6.9040400@gmail.com> Message-ID: <4A3A17FC.5080600@gmail.com> Simon Marlow wrote: > I'm an infrequent etags user, and I never use ctags. The problem is I do not know whether I should try to improve etags too. So far I tried to keep them the same they were. The only difference I know about is that if more tags happen to exist on the same source line then they may have different order (but only within the group of the symbols on the line). This is probably because different GHC interface is used and the symbols are coming in different order. Vim can accept emacs tags too and they work fine as they are generated by the new code. So the questions for emacs users are: * Should the non-exported top level symbols be added to emacs TAGS file? As far as I could find on the internet, emacs does not have notion of "static" symbols as vim has so it may not be a good idea. But if emacs prefers jump to a symbol in the local file to symbols in the other files it may work well enough to be worth it. * The last data field of the tag definition is "byte_offset". But in past (and I kept it as it was so even when the patch is applied) this was actually byteOffset-numberOfLines*sizeOfLineDelimiter. The size of newLine delimiters was ignored (and moreover it is system dependent). This does not matter that much since based on Claus information emacs allows some fuzz in the position information. The question is whether to keep this as it was or add 1 for each line or somehow try to detect platform and add the correct number of bytes for each line? If no answers come I just keep it as it is and hope for the support of the vim related ctags changes only :) Peter. From jwlato at gmail.com Thu Jun 18 06:46:40 2009 From: jwlato at gmail.com (John Lato) Date: Thu Jun 18 06:29:52 2009 Subject: question about -fno-pre-inlining In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4B86AF58@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0906180158h54b43a0fk88e9e0fc41ba5ca6@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33F4B86AF58@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <9979e72e0906180346h60ddc0b3yd73e7c8157085249@mail.gmail.com> Simon, Thanks for the quick reply, and also the link. I'll be sure to read it. I don't know what pre-inlining is; I was testing different compiler options with acovea, which indicated the performance boost. When I tried it myself, I noticed the differing value. I'm pretty sure the affected code is in a library I'm developing. If I turn off pre-inlining when compiling the library I get the same final value as when turning it off in just the test program, although performance is markedly worse. Unfortunately that doesn't narrow it down much; there are several modules in the library. The algorithm shouldn't be particularly sensitive. I'm just normalize Ints to Doubles in the range +- 1.0 and finding the maximum. I'm not using the FFI, but there are a few questionable tactics employed. In particular, I'm doing both: 1. Casting Ptr's (in IO). 2. Using an Int24 data type that has operations on unboxed Int#'s, similar to Int16's implementation. Of course the problem may be unrelated to both of these. I just wanted to find out if this was expected or not before I attempt to isolate it, because that will take a bit of work. I'll see what I can do, but it may be a while before I make any progress. Cheers, John On Thu, Jun 18, 2009 at 11:16 AM, Simon Peyton-Jones wrote: > John > > | When compiled with -fno-pre-inlining, my test program gives a > | different result than compiled without (0.988... :: Double, compared > | to 1.0). ?It's numerical code, and was originally compiled with > > That's entirely unexpected. I am very surprised that turning off pre-inlining > a) affects the results at all > b) improves performance > > Of course this is a floating point program, where various numeric transformations are invalid if you want bit-for-bit accuracy. ?(eg addition is not associative). ? But a 2% change seems big, unless it's a very sensitive algorithm. > > To find out what "pre-inlining" is read Section 5 of > http://research.microsoft.com/en-us/um/people/simonpj/papers/inlining/inline-jfp.ps.gz > It's called "PreInlineUnconditionally" there. > > I'm not sure how to proceed. ?The more you can boil it down, the easier it'll be to find out what is going on. ?One way to do this is to make the program smaller. But even finding out which function is sensitive to the setting of -fno-pre-inlining would be interesting. ?(You can't set this on a function by function basis, so you'll have to split the module.) > > If you can make a self-contained test case, do make a Trac ticket for it. > > Are you using the FFI? > > All very odd. > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of John Lato > | Sent: 18 June 2009 09:58 > | To: glasgow-haskell-users@haskell.org > | Subject: question about -fno-pre-inlining > | > | Hello, > | > | I was experimenting with compiler flags trying to tune some > | performance and got something unexpected with the -fno-pre-inlining > | flag. ?I was hoping somebody here might be able to clarify an issue > | for me. > | > | When compiled with -fno-pre-inlining, my test program gives a > | different result than compiled without (0.988... :: Double, compared > | to 1.0). ?It's numerical code, and was originally compiled with > | -fexcess-precision, however I have tried both with and without > | -fexcess-precision and the results are the same. ?The only other > | compiler flags in use are -O2 and --make. ?Is this expected behavior > | or a possible bug? ?I believe the value with -fno-pre-inlining is > | correct (and runs about 30% faster too). > | > | This was done on an OSX 10.5 Macbook with GHC-6.10.3. ?I could check > | this on some other systems if it would be helpful. > | > | Sincerely, > | John Lato > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From niklas.broberg at gmail.com Thu Jun 18 07:08:41 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jun 18 06:51:53 2009 Subject: Three patches for cabal In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F6C8@ELON17P32001A.csfb.cs-group.com> References: <1245230688.13502.2939.camel@localhost> <16442B752A06A74AB4D9F9A5FF076E4B03B9F6C8@ELON17P32001A.csfb.cs-group.com> Message-ID: > In general I think there is a reasonable case for special treatment for > exceptions to H98 that have been accepted for haskell-prime. I'm not sure I agree with this. I'm not involved in the H' process, but it was my impression that the general state of affairs was a move towards a modularization of the standard, so instead of a single monolithic Haskell' language we would have a series of blessed addendums like we already have with e.g. the hierarchical module namespace or FFI. If that's the case then having each of those addendums enumerated as extensions makes perfect sense to me, at least until a H' standard (in whatever form) is actually released. That said, this really have little bearing on the current discussion, since as you say this particular case won't make it to H' anyway. I don't really see any good arguments why MonoPatBinds shouldn't be the listed extension. Cheers, /Niklas From ml at isaac.cedarswampstudios.org Thu Jun 18 11:09:33 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Thu Jun 18 10:53:05 2009 Subject: Three patches for cabal In-Reply-To: <1245230688.13502.2939.camel@localhost> References: <1245230688.13502.2939.camel@localhost> Message-ID: <4A3A58AD.3060705@isaac.cedarswampstudios.org> Duncan Coutts wrote: > In practise, since ghc uses MonoPatBinds by default it'd mean that > people who want to get back to H98 would need to use: > > ghc-options: -XNoMonoPatBinds > > Because the extensions field is additive, not subtractive. Using the > name MonoPatBinds allows other compilers to implement it without it > having to be the default. hmm, that's annoying. Is it feasible for the extensions field to allow both addition and subtraction that override compiler defaults? (How does it work in LANGUAGE pragmas -- would NoMonoPatBinds still work in one of them?) -Isaac From niklas.broberg at gmail.com Thu Jun 18 13:14:26 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jun 18 12:57:38 2009 Subject: Three patches for cabal In-Reply-To: <4A3A58AD.3060705@isaac.cedarswampstudios.org> References: <1245230688.13502.2939.camel@localhost> <4A3A58AD.3060705@isaac.cedarswampstudios.org> Message-ID: > hmm, that's annoying. ?Is it feasible for the extensions field to allow both > addition and subtraction that override compiler defaults? ?(How does it work > in LANGUAGE pragmas -- would NoMonoPatBinds still work in one of them?) It would only work during the period of deprecation, and would obviously be discouraged then. You could use OPTIONS_GHC pragmas with -XNoMonoPatBinds instead though. Why is it annoying specifically? Cheers, /Niklas From niklas.broberg at gmail.com Thu Jun 18 17:18:48 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jun 18 17:01:58 2009 Subject: Strangeness in the syntax of types Message-ID: Hi all, I've had a curious bug report [1] for haskell-src-exts, pointing to a difference in behavior between haskell-src-exts and GHC. Digging further, it seems to me like GHC is behaving quite strange in this instance, but since we don't have formal documentation for the extensions I can't be sure. I'm *almost* convinced this is a bug in GHC, but with these type extensions I can never be quite sure. Thus I'm putting it out here in the hope that someone will either explain why it is this way, or tell me to go file a bug report. The gist of it is the following piece of code: > multipleCtx :: Eq a => Show a => a > multipleCtx = undefined GHC accepts this code, while haskell-src-exts requires parentheses around the latter part of the signature, i.e. Eq a => (Show a => a). The difference is the following productions haskell-src-exts: > ctype :: { PType } > : 'forall' ktyvars '.' ctype > | context '=>' type > | type GHC: > ctypedoc :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctypedoc > | context '=>' ctypedoc > | gentypedoc Notice GHC's recursive call to ctypedoc after the =>. I have no idea what the doc suffix on the production is intended to indicate though - and I was curious to find a separate set of rules that don't have that suffix: > ctype :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctype > | context '=>' type > | type This one looks just like the one that haskell-src-exts uses - type instead of ctype after the =>. So what's the difference between the two in GHC? Looking further, the former is used in top-level type signatures, while the latter is used for pretty much everything else. In particular, you can't put a ctypedoc inside parentheses, there you would have to use ctype. So while GHC accepts the above definition, it rejects e.g. the (seemingly) equivalent > multipleCtx :: (Eq a => Show a => a) > multipleCtx = undefined My guess would be that there's a bug here, and that it's the recursive call to ctypedoc that is at fault, it should really be gentypedoc. On the other hand there's no problem parsing either, so there's no technical reason not to allow chained contexts without parentheses, even though I personally think it looks quite awkward. Enough rambling - can someone make me the wiser? Cheers, /Niklas [1] http://trac.haskell.org/haskell-src-exts/ticket/37 From david.waern at gmail.com Thu Jun 18 18:05:26 2009 From: david.waern at gmail.com (David Waern) Date: Thu Jun 18 17:48:36 2009 Subject: Strangeness in the syntax of types In-Reply-To: References: Message-ID: 2009/6/18 Niklas Broberg : > GHC: >> ctypedoc ?:: { LHsType RdrName } >> ? ? ? ?: 'forall' tv_bndrs '.' ctypedoc >> ? ? ? ?| context '=>' ctypedoc >> ? ? ? ?| gentypedoc > > Notice GHC's recursive call to ctypedoc after the =>. I have no idea > what the doc suffix on the production is intended to indicate though - > and I was curious to find a separate set of rules that don't have that > suffix: The doc suffix says "can contain Haddock comments". >> ctype :: { LHsType RdrName } >> ? ? ? : 'forall' tv_bndrs '.' ctype >> ? ? ? | context '=>' type >> ? ? ? | type > > This one looks just like the one that haskell-src-exts uses - type > instead of ctype after the =>. You're not looking at the latest version of the code. I'm guessing you're looking at the stable version instead of the HEAD. In HEAD we have: > ctypedoc :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctypedoc { LL $ mkExplicitHsForAllTy $2 (noLoc []) $4 } > | context '=>' ctypedoc { LL $ mkImplicitHsForAllTy $1 $3 } > -- A type of form (context => type) is an *implicit* HsForAllTy > | ipvar '::' type { LL (HsPredTy (HsIParam (unLoc $1) $3)) } > | typedoc { $1 } This should accept both > multipleCtx :: (Eq a => Show a => a) > multipleCtx = undefined and > multipleCtx :: Eq a => Show a => a > multipleCtx = undefined The reason why ctypedoc and ctype were so different before, is because they drifted apart after ctypedoc was added. ctype was changed (I think during implementation of the TypeFamilies extension) without any changes to ctypedoc. This was fixed in HEAD not so long ago. If you need more information I can dig up the trac ticket :-) David From niklas.broberg at gmail.com Thu Jun 18 19:19:50 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jun 18 19:03:00 2009 Subject: Strangeness in the syntax of types In-Reply-To: References: Message-ID: > You're not looking at the latest version of the code. I'm guessing > you're looking at the stable version instead of the HEAD. Indeed, I'm looking at the source distribution for 6.10.3, since that's the reference version I use to test the files. >> ctypedoc :: { LHsType RdrName } >> ? ? ? : 'forall' tv_bndrs '.' ctypedoc ? ? ? ?{ LL $ mkExplicitHsForAllTy $2 (noLoc []) $4 } >> ? ? ? | context '=>' ctypedoc ? ? ? ? { LL $ mkImplicitHsForAllTy ? $1 $3 } >> ? ? ? -- A type of form (context => type) is an *implicit* HsForAllTy >> ? ? ? | ipvar '::' type ? ? ? ? ? ? ? { LL (HsPredTy (HsIParam (unLoc $1) $3)) } >> ? ? ? | typedoc ? ? ? ? ? ? ? ? ? ? ? { $1 } > > This should accept both > >> multipleCtx :: (Eq a => Show a => a) >> multipleCtx = undefined > > and > >> multipleCtx :: Eq a => Show a => a >> multipleCtx = undefined > > The reason why ctypedoc and ctype were so different before, is because > they drifted apart after ctypedoc was added. ctype was changed (I > think during implementation of the TypeFamilies extension) without any > changes to ctypedoc. This was fixed in HEAD not so long ago. Thanks a lot for the information, then I know. So the correct thing to do is to put a ctype in the recursive position after the context. I sorely wish these things were better documented... Cheers, /Niklas From allbery at ece.cmu.edu Thu Jun 18 21:28:46 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jun 18 21:12:18 2009 Subject: GADT record syntax and contexts In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1245060558.25705.17.camel@ewi1043> <638ABD0A29C8884A91BC5FB5C349B1C33F4B43E689@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Jun 16, 2009, at 05:19 , Simon Peyton-Jones wrote: > (B) data RecTest a where > B :: { arg :: a } -> RecTest a For what it's worth (considering that I have yet to actually use GADTs), (A) looks wrong to me because there is type information before the actual type. (B) looks kinda strange as well, but the "missing" tycon seems to make more sense given that it's a GADT. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090618/f6b7a8d5/PGP.bin From igloo at earth.li Fri Jun 19 16:05:32 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 19 15:48:40 2009 Subject: Three patches for cabal In-Reply-To: <1245230688.13502.2939.camel@localhost> References: <1245230688.13502.2939.camel@localhost> Message-ID: <20090619200532.GA25532@matrix.chaos.earth.li> On Wed, Jun 17, 2009 at 10:24:48AM +0100, Duncan Coutts wrote: > > Deprecating PatternSignatures seems uncontroversial, but the > NoMonoPatBinds is potentially controversial. GHC essentially uses > -XMonoPatBinds by default, even in H98 mode, and the user can use > -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that > the list of language extensions in Language.Haskell.Exceptions are > differences from H98 so it should be MonoPatBinds to get the difference > not NoMonoPatBinds to restore H98. > > In practise, since ghc uses MonoPatBinds by default it'd mean that > people who want to get back to H98 would need to use: > > ghc-options: -XNoMonoPatBinds I think that Cabal should allow any extension to be listed as either Foo or NoFoo, just as GHC does in a -X flag or a LANGUAGE pragma. This will also be useful if we get extension groups like Haskell'2009 and Haskell'2010, where you might want to say something like: Haskell'2010 minus ExistentialQuantification Thanks Ian From igloo at earth.li Fri Jun 19 16:31:05 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 19 16:14:13 2009 Subject: build question: ghc 6.11.20090605 -> ghc 6.10.3? In-Reply-To: <65d7a7e0906071504l43d8e7bo17330539fb172e5@mail.gmail.com> References: <65d7a7e0906071504l43d8e7bo17330539fb172e5@mail.gmail.com> Message-ID: <20090619203105.GB25532@matrix.chaos.earth.li> Hi Uwe, Sorry for the slow response. On Sun, Jun 07, 2009 at 03:04:44PM -0700, Uwe Hollerbach wrote: > Hi, all, is it expected that a snapshot version (I'm using 2009.06.05) > should be able to build the released version 6.10.3? No: In order to compile the 6.10.3 release you need to use a released version of GHC between version 6.6 and version 6.10.3 (inclusive). > This weekend I > tried the "porting to an unsupported machine" procedure with the > aforementioned snapshot version; that worked, after some fussing, and > I seem to have a working ghc install, including several libraries and > cabal. Great! > But I tried building the Haskell Platform, and it warns > (rightly, as it turns out) about this being an unsupported version of > ghc. So I'd like to get onto the regular release train, as it were, > and transfer myself to ghc 6.10.3. In order to do this, you'd have to get your hands dirty. The 6.10.3 source didn't know what differences there would be in your snapshot, so it doesn't have any support for them. You'd need to add this support to the 6.10.3 build system. If you've got cabal-install working then you can just cabal-install the libraries that you want, of course. You may have problems with some of them not working due to the changes in your snapshot, though. When 6.12.1 is released you might be able to compile it with your snapshot, but that isn't guaranteed. It's likely to be easier than building 6.10.3 would be, though. If nothing else, the porting procedure will work for 6.12.1. > PS I suppose I should describe in a little bit of detail what I did > for the porting, might be useful for someone else trying this. It was > a rather vanilla port, x86_64-unknown-linux to same; my target machine > is my workstation at work, where I don't have root, and I do have > permission from IT to install this stuff, but no support... so they > won't install rpms for me, or anything like that. It's also a slightly > old and somewhat customized version of some RedHat corporate release, > so recent plain-vanilla tarballs didn't work... hence the need to > port. Another possibility would be to go back to the tarball of an earlier version of GHC, and then to use that to compile the newer version. > The third issue was the sed syntax on the same page: the version of > sed that I was using didn't like the space between the "-i" and the > ".bak". I don't know if that's a variation from one version of sed to > another, or a typo on the page, or??? Again no big deal, the error > message from sed was informative enough for me to figure out what to > do. I've removed the space, thanks. Thanks Ian From iainspeed at gmail.com Sat Jun 20 08:09:48 2009 From: iainspeed at gmail.com (Iain Barnett) Date: Sat Jun 20 07:53:19 2009 Subject: was 6.10.3 prerelease Message-ID: <847505D7-7E4B-400A-9712-4EDEDE771D58@gmail.com> In reference to http://www.nabble.com/6.10.3-prerelease-td23346957.html I also run Mac OSX 10.4.11 (there are some left) and I experience the same problem but with the full release of 6.10.3 from source. I've read the discussion and the trac ticket at http:// hackage.haskell.org/trac/ghc/ticket/3243, but I have no idea how to actually get and apply the patch. Sorry if I'm being incredibly thick, (or even just a bit thick) but I have barely used C or darcs (though I do have darcs installed). Any advice on how to fix this is much appreciated - originally I just wanted to upgrade Cabal but when it didn't work I tried to upgrade GHC, and now I seem to be digging a big hole! Iain From matthijs at stdin.nl Sat Jun 20 13:18:04 2009 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Sat Jun 20 13:01:12 2009 Subject: How unique is a Unique? Message-ID: <20090620171804.GW1611@katherina.student.utwente.nl> Hi all, I've been doing some work with the GHC API, and I'm kind of confused as to how Uniques are supposed to work. I've found that each Name has a Unique that is its primary identification (at least for internal names). That means that two identifiers are different iff their Uniques are different, even when their OccNames are the same. This also means that two identifiers are equal when their Uniques are equal, even if their OccNames are different (though I think this situations is not supposed to exist and is really undefined?). Now, from the name "Unique", one would assume that each different identifier in a compiler run gets a different Unique, even when they are in different functions or modules. However, I've found some evidence to suggest otherwise. In particular, I've been looking at applying substitutions using CoreSubst. As a part of a substitution, the set of identifiers that are in scope are included with the substitutions to perform. I don't completely understand the requirements on this InScopeSet, but I do see that any identifiers that are bound in the to-be-substituted-in expression that are also in scope, will have their Unique changed. This makes sense when you want Uniques to be really unique, since \a_1 -> \a_1 -> \a_1 will then become \a_1 -> \a_2 -> \a_2. This does not sound related to substitution, but apparantly substition always performs this de-shadowing (as I think it's called?) implicitely. Giving this some further thought, it makes some sense, since when I'm performing the substituion \x_3 -> a_4 (which has a free variable a_4), on the expression \a_4 -> x_3, this must of course result in \a_5 -> a_4, not \a_4 -> a_4. So, it seems the InScopeSet should at least contain the free variables of the substited values. Looking a bit closer, this might be exactly what the definition at CoreSubst says: "Precisely, the in-scope set must be a superset of the free vars of the substitution range that might possibly clash with locally-bound variables in the thing being substituted in." I'm not completely sure what the "substituion range" is, but I can imagine this being the expression part of a binder -> expression substitution? Anyway, back to my original point. The above suggests that Uniques are not so unique after all. If every binder everywhere would get its own Unique, the Unique replacement CoreSubst does would never be neccesary. So, how is the uniqueness of Unique really defined? I can imagine that the generation of new Uniques is avoided as much as possible for performance reasons, and thus uniqueness is guaranteed only "on demand", by running deshadowing / substitutions when things could be clashing? Any thoughts on what kind of non-uniqueness is allowed and what is not? Are there common pitfalls when working with uniques? When to apply deshadowing or other uniqueness generating techniques? On a related note, is my understanding correct that deshadowing will only provide uniqueness on each "path" through the expression tree, and not over the entire tree? i.e., the expression let x_6 = \y_7 -> y_7; z_8 = \y_7 -> \y_7 in x_6 is a deshadowed expressions, even though both of the y_7 lambda binders refer to a different variable? If so, is there any function that gives complete uniqueness over an entire tree? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090620/8d2af73f/attachment-0001.bin From ganesh at earth.li Sat Jun 20 16:46:13 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Jun 20 16:29:18 2009 Subject: finalizers on handles Message-ID: 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 From ndmitchell at gmail.com Sun Jun 21 14:14:44 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jun 21 13:57:46 2009 Subject: group keyword with TransformListComp Message-ID: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.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 From dons at galois.com Sun Jun 21 15:34:45 2009 From: dons at galois.com (Don Stewart) Date: Sun Jun 21 15:19:44 2009 Subject: group keyword with TransformListComp In-Reply-To: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> References: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> Message-ID: <20090621193445.GA2638@whirlpool.galois.com> Don't use TransformListComp ?? -- Don ndmitchell: > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Mon Jun 22 05:13:35 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jun 22 04:56:38 2009 Subject: was 6.10.3 prerelease In-Reply-To: References: <847505D7-7E4B-400A-9712-4EDEDE771D58@gmail.com> Message-ID: <4A3F4B3F.5010404@dfki.de> Maybe a binary distribution for Mac OS Tiger would be useful. (I prefer the plain .tar.gz files over .pkg, because they don't require root rights.) I usually make them using a file mk/build.mk containing: BIN_DIST=1 Project=Ghc HADDOCK_DOCS = YES #XMLDocWays = html using the commands: ./configure make make binary-dist I can offer binary dists for x68 under Solaris and PPC Mac OS 10.5 (Leopard), the latter depending on: /opt/local/lib/libiconv.2.dylib /opt/local/lib/libncurses.5.dylib /opt/local/lib/libgmp.3.dylib Cheers Christian http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.3-i386-unknown-solaris2.tar.bz2 http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.3-powerpc-apple-darwin.tar.bz2 Yusaku Hashimoto wrote: > It is problem about the library for dealing OS process. This bug is > fixed, and fixed version of process is in the repository. You can check > out latest library from http://darcs.haskell.org/packages/process and > replace the library in the build directory (libraries/process). > > If you are bothered to this, you can just comment-in a line 90 (maybe > near of here...) in libraries/process/cbits/runProcess.c to > disableItimers() in the child process. > > HTH, > Hashimoto > > On 2009/06/20, at 21:09, Iain Barnett wrote: > >> In reference to http://www.nabble.com/6.10.3-prerelease-td23346957.html >> >> I also run Mac OSX 10.4.11 (there are some left) and I experience the >> same problem but with the full release of 6.10.3 from source. I've >> read the discussion and the trac ticket at >> http://hackage.haskell.org/trac/ghc/ticket/3243, but I have no idea >> how to actually get and apply the patch. >> >> Sorry if I'm being incredibly thick, (or even just a bit thick) but I >> have barely used C or darcs (though I do have darcs installed). Any >> advice on how to fix this is much appreciated - originally I just >> wanted to upgrade Cabal but when it didn't work I tried to upgrade >> GHC, and now I seem to be digging a big hole! >> >> Iain >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Tue Jun 23 09:41:41 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 23 09:24:40 2009 Subject: finalizers on handles In-Reply-To: References: Message-ID: <4A40DB95.9050703@gmail.com> On 20/06/2009 21:46, Ganesh Sittampalam wrote: > 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. Interesting example. So what should we do? Don't finalize an FD if it might have an externally visible effect? That seems a bit extreme. Anyone else have any thoughts on this? Cheers, Simon From ganesh.sittampalam at credit-suisse.com Tue Jun 23 10:23:44 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Jun 23 10:07:05 2009 Subject: finalizers on handles In-Reply-To: <4A40DB95.9050703@gmail.com> References: <4A40DB95.9050703@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F6E6@ELON17P32001A.csfb.cs-group.com> Simon Marlow wrote: > On 20/06/2009 21:46, Ganesh Sittampalam wrote: > >> 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. > > Interesting example. So what should we do? Don't finalize an FD if > it might have an externally visible effect? That seems a bit > extreme. I'm not really sure what to do either, otherwise I'd have suggested something concrete in my first email :-) One problem is that any move away from having the finalizer on every handle could easily lead to much more confusion than the current sitation. I guess an important question is what the benefits of having the finalizer are. Presumably it really is needed in the hGetContents case, since users should be able to just drop the lazy stream and have everything associated with it go away. Since other file operations are done eagerly, isn't it also reasonable to expect the user to exert explicit control over the handle in those cases? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From simonpj at microsoft.com Tue Jun 23 11:12:18 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 23 10:55:16 2009 Subject: group keyword with TransformListComp In-Reply-To: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> References: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFB18@EA-EXMSG-C334.europe.corp.microsoft.com> I don't mind what keyword (or indeed syntax) we use! Better alternatives welcome. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Neil Mitchell | Sent: 21 June 2009 19:15 | To: glasgow-haskell-users@haskell.org; Max Bolingbroke | Subject: group keyword with TransformListComp | | 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 | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Tue Jun 23 11:17:17 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 23 11:00:20 2009 Subject: How unique is a Unique? In-Reply-To: <20090620171804.GW1611@katherina.student.utwente.nl> References: <20090620171804.GW1611@katherina.student.utwente.nl> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFB2D@EA-EXMSG-C334.europe.corp.microsoft.com> Matthis | Now, from the name "Unique", one would assume that each different identifier | in a compiler run gets a different Unique, even when they are in different | functions or modules. However, I've found some evidence to suggest otherwise. Indeed, that's not so. The thing to read is Section 4 of: http://research.microsoft.com/en-us/um/people/simonpj/papers/inlining/index.htm That tells you all about the InScopeSet etc. I hope that helps. If you are still stuck after reading that, ask again. Would you like to record the answers you find somewhere in the GHC Commentary? http://hackage.haskell.org/trac/ghc/wiki/Commentary I imagine you have been looking there for clues anyway? It's a wiki, so you can improve it! thanks Simon From simonpj at microsoft.com Tue Jun 23 11:37:03 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 23 11:20:03 2009 Subject: Strangeness in the syntax of types In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFB76@EA-EXMSG-C334.europe.corp.microsoft.com> | > The reason why ctypedoc and ctype were so different before, is because | > they drifted apart after ctypedoc was added. ctype was changed (I | > think during implementation of the TypeFamilies extension) without any | > changes to ctypedoc. This was fixed in HEAD not so long ago. | | Thanks a lot for the information, then I know. So the correct thing to | do is to put a ctype in the recursive position after the context. I | sorely wish these things were better documented... Me too. But you know the reason: so much to do, so little time. Plus, if code drifts apart from code (as it did above), you may imagine that document drifts apart from code even more. The best thing to do, I think, is to comment the code liberally. I particularly recommend the Note [blah] comments described in http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle If you'd like to add some such clarifying notes to Parser.y.pp, that'd be great. We'd gladly check them for veracity! Simon From bulat.ziganshin at gmail.com Tue Jun 23 17:28:39 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jun 23 17:11:40 2009 Subject: wiki page on GHC GC Message-ID: <239751867.20090624012839@gmail.com> i have started http://haskell.org/haskellwiki/GHC/Memory_Management - not much written yet -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From niklas.broberg at gmail.com Tue Jun 23 20:32:24 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Jun 23 20:15:21 2009 Subject: Proposal: ExplicitForall Message-ID: 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 From allbery at ece.cmu.edu Tue Jun 23 22:07:26 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Jun 23 21:50:30 2009 Subject: finalizers on handles In-Reply-To: <4A40DB95.9050703@gmail.com> References: <4A40DB95.9050703@gmail.com> Message-ID: <35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> On Jun 23, 2009, at 09:41 , Simon Marlow wrote: >> main = do >> (ih, oh, _, _) <- runInteractiveProcess "cat" [] Nothing Nothing >> comphszp <- hGetContents oh >> print (length comphszp) >> -- hClose ih -- with this line they both deadlock Note that you can trigger this in any language; it's a classic beginner error with pipes (see, for example, the documentation for open2/open3 in Perl or Python for other examples). Detecting this in the type system would be an interesting idea, but de facto I think this is a "it hurts when I do this". -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090623/da73e97c/PGP.bin From ganesh at earth.li Wed Jun 24 00:52:19 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed Jun 24 00:35:14 2009 Subject: finalizers on handles In-Reply-To: <35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> References: <4A40DB95.9050703@gmail.com> <35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> Message-ID: On Tue, 23 Jun 2009, Brandon S. Allbery KF8NH wrote: > On Jun 23, 2009, at 09:41 , Simon Marlow wrote: >>> main = do >>> (ih, oh, _, _) <- runInteractiveProcess "cat" [] Nothing Nothing >>> comphszp <- hGetContents oh >>> print (length comphszp) >>> -- hClose ih -- with this line they both deadlock > > > Note that you can trigger this in any language; it's a classic beginner > error with pipes (see, for example, the documentation for open2/open3 in > Perl or Python for other examples). Detecting this in the type system > would be an interesting idea, but de facto I think this is a "it hurts > when I do this". Sure - but it hurts more when in some environments you get away with it and others you don't. Ganesh From allbery at ece.cmu.edu Wed Jun 24 00:56:30 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jun 24 00:39:42 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: Message-ID: On Jun 23, 2009, at 20:32 , Niklas Broberg wrote: > 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. Someone really needs to sit down and work out a complete, consistent, and rational set of extensions, including not only your ExplicitForall but also e.g. if you are actually compiling Haskell98, hierarchical modules should be illegal. The reality is that some extensions are always on and others are haphazardly split from -fglasgow-exts. (Then again, I'm also of the opinion that -package should control not only linking but also imports, because it's ridiculously inconsistent for stuff to compile but not link if you forget -package or --make. It also opens the possibility of modules managing their own namespaces as discussed in other recent threads, and that a module install doesn't have to scribble in ghc's library directory; the latter would likely make some packagers very happy.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090624/1f8c5dc3/PGP.bin From allbery at ece.cmu.edu Wed Jun 24 01:03:28 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jun 24 00:46:30 2009 Subject: finalizers on handles In-Reply-To: References: <4A40DB95.9050703@gmail.com> <35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> Message-ID: <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> On Jun 24, 2009, at 00:52 , Ganesh Sittampalam wrote: > On Tue, 23 Jun 2009, Brandon S. Allbery KF8NH wrote: > On Jun 23, 2009, at 09:41 , Simon Marlow wrote: >>>> main = do >>>> (ih, oh, _, _) <- runInteractiveProcess "cat" [] Nothing Nothing >>>> comphszp <- hGetContents oh >>>> print (length comphszp) >>>> -- hClose ih -- with this line they both deadlock >> >> >> Note that you can trigger this in any language; it's a classic >> beginner error with pipes (see, for example, the documentation for >> open2/open3 in Perl or Python for other examples). Detecting this >> in the type system would be an interesting idea, but de facto I >> think this is a "it hurts when I do this". > > Sure - but it hurts more when in some environments you get away with > it and others you don't. You'll still have that though, it'll just be a different set of environments. The next failure mode after this one is writing more than _PIPE_BUF down ih; you'll deadlock in the write when in blocking mode, in non-blocking mode it depends on how the runtime handles partial writes. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090624/8b243c2f/PGP.bin From ganesh.sittampalam at credit-suisse.com Wed Jun 24 02:27:22 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Jun 24 02:10:51 2009 Subject: finalizers on handles In-Reply-To: <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> References: <4A40DB95.9050703@gmail.com><35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F1@ELON17P32001A.csfb.cs-group.com> Brandon S. Allbery KF8NH wrote: >> Sure - but it hurts more when in some environments you get away with >> it and others you don't. > > > You'll still have that though, it'll just be a different set of > environments. The next failure mode after this one is writing more > than _PIPE_BUF down ih; you'll deadlock in the write when in blocking > mode, in non-blocking mode it depends on how the runtime handles > partial writes. I'd hope for consistency across the GHC runtimes though. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From allbery at ece.cmu.edu Wed Jun 24 02:33:32 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jun 24 02:16:32 2009 Subject: finalizers on handles In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F1@ELON17P32001A.csfb.cs-group.com> References: <4A40DB95.9050703@gmail.com><35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F1@ELON17P32001A.csfb.cs-group.com> Message-ID: <1D0F1BC6-DA4B-40F5-AFD4-0777750CC2BC@ece.cmu.edu> On Jun 24, 2009, at 02:27 , Sittampalam, Ganesh wrote: > Brandon S. Allbery KF8NH wrote: > >>> Sure - but it hurts more when in some environments you get away with >>> it and others you don't. >> >> You'll still have that though, it'll just be a different set of >> environments. The next failure mode after this one is writing more >> than _PIPE_BUF down ih; you'll deadlock in the write when in blocking >> mode, in non-blocking mode it depends on how the runtime handles >> partial writes. > > I'd hope for consistency across the GHC runtimes though. You can hope, but I get the impression blocking/non-blocking maps to threaded/non-threaded respectively in which case all bets are off. (Unless the ghc runtime guarantees some specific behavior here.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090624/263c3a5a/PGP-0001.bin From ganesh.sittampalam at credit-suisse.com Wed Jun 24 02:46:31 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Jun 24 02:29:45 2009 Subject: finalizers on handles In-Reply-To: <1D0F1BC6-DA4B-40F5-AFD4-0777750CC2BC@ece.cmu.edu> References: <4A40DB95.9050703@gmail.com><35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F1@ELON17P32001A.csfb.cs-group.com> <1D0F1BC6-DA4B-40F5-AFD4-0777750CC2BC@ece.cmu.edu> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F2@ELON17P32001A.csfb.cs-group.com> Brandon S. Allbery KF8NH wrote: > On Jun 24, 2009, at 02:27 , Sittampalam, Ganesh wrote: >> Brandon S. Allbery KF8NH wrote: >> >>>> Sure - but it hurts more when in some environments you get away >>>> with it and others you don't. >>> >>> You'll still have that though, it'll just be a different set of >>> environments. The next failure mode after this one is writing more >>> than _PIPE_BUF down ih; you'll deadlock in the write when in >>> blocking mode, in non-blocking mode it depends on how the runtime >>> handles partial writes. >> >> I'd hope for consistency across the GHC runtimes though. > > > You can hope, but I get the impression blocking/non-blocking maps to > threaded/non-threaded respectively in which case all bets are off. > (Unless the ghc runtime guarantees some specific behavior here.) I believe that from the point of view of each Haskell thread, the IO will always be blocking (unless you explicitly used a non-blocking call), but the GHC runtime actually handles the IO using select and non-blocking calls, and so avoids blocking the entire program, and that this doesn't vary between the threaded and non-threaded runtimes. That's why I found it confusing that a program that just did IO could behave differently on the two runtimes, until I found the bug in it. Ideally, the program would have deadlocked on both runtimes. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From simonpj at microsoft.com Wed Jun 24 04:09:52 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jun 24 03:52:56 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> | I would thus like to propose the following formalisation of the | ExplicitForall extension: What you suggest would be fine with me. Presumably ExplicitForall would be implied by RankNTypes and the other extensions? There is a danger of having too *many* choices. (http://www.joelonsoftware.com/items/2006/11/21.html) In particular, you might consider making ScopedTypeVariables synonymous with ExplicitForAll. Once you have given up the keyword, it seems a shame not to allow lexically scoped type variables! On ExistentialQuantification, I personally think we should deprecate the entire construct, suggesting GADT-style syntax instead. If you can form a consensus, go for it. Simon From marlowsd at gmail.com Wed Jun 24 04:10:55 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 24 03:53:52 2009 Subject: wiki page on GHC GC In-Reply-To: <239751867.20090624012839@gmail.com> References: <239751867.20090624012839@gmail.com> Message-ID: <4A41DF8F.6040108@gmail.com> On 23/06/2009 22:28, Bulat Ziganshin wrote: > i have started http://haskell.org/haskellwiki/GHC/Memory_Management - > not much written yet You could link to the recent paper about the parallel GC, it has plenty of information about the architecture of the GC (not just relevant to parallel GC): http://www.haskell.org/~simonmar/bib/parallel-gc-08_abstract.html Also, you probably want to link your new page from http://haskell.org/haskellwiki/GHC. Cheers, Simon From marlowsd at gmail.com Wed Jun 24 05:04:53 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jun 24 04:47:50 2009 Subject: finalizers on handles In-Reply-To: <1D0F1BC6-DA4B-40F5-AFD4-0777750CC2BC@ece.cmu.edu> References: <4A40DB95.9050703@gmail.com><35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F1@ELON17P32001A.csfb.cs-group.com> <1D0F1BC6-DA4B-40F5-AFD4-0777750CC2BC@ece.cmu.edu> Message-ID: <4A41EC35.4000804@gmail.com> On 24/06/2009 07:33, Brandon S. Allbery KF8NH wrote: > On Jun 24, 2009, at 02:27 , Sittampalam, Ganesh wrote: >> Brandon S. Allbery KF8NH wrote: >> >>>> Sure - but it hurts more when in some environments you get away with >>>> it and others you don't. >>> >>> You'll still have that though, it'll just be a different set of >>> environments. The next failure mode after this one is writing more >>> than _PIPE_BUF down ih; you'll deadlock in the write when in blocking >>> mode, in non-blocking mode it depends on how the runtime handles >>> partial writes. >> >> I'd hope for consistency across the GHC runtimes though. > > > You can hope, but I get the impression blocking/non-blocking maps to > threaded/non-threaded respectively in which case all bets are off. > (Unless the ghc runtime guarantees some specific behavior here.) GHC uses non-blocking mode for all FDs that are "internal", i.e. not shared with external processes. This is the case for both the threaded and non-threaded RTSs. The difference between blocking/non-blocking mode and the size of PIPE_BUF should be mostly invisible to the Haskell programmer (although see http://hackage.haskell.org/trac/ghc/ticket/3316 for a bug we have in this area, which I fixed yesterday). There's one exception: if GHC is forced to use blocking mode on a particular FD, and you're using the non-threaded RTS, then a large write using hPutBuf may block all Haskell threads. There doesn't seem to be much we can do about this, except to use the threaded RTS or lobby the Linux kernel guys for a better API. Cheers, Simon From niklas.broberg at gmail.com Wed Jun 24 06:59:56 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 24 06:42:50 2009 Subject: Proposal: ExplicitForall In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: > What you suggest would be fine with me. Presumably ExplicitForall would be implied by RankNTypes and the other extensions? Yes, that's the idea. Rank2Types, RankNTypes, PolymorphicComponents, ScopedTypeVariables and LiberalTypeSynonyms would all imply ExplicitForall. > There is a danger of having too *many* choices. (http://www.joelonsoftware.com/items/2006/11/21.html) ?In particular, you might consider making ScopedTypeVariables synonymous with ExplicitForAll. ?Once you have given up the keyword, it seems a shame not to allow lexically scoped type variables! While I agree with you (and Joel) in principle, I think this is the wrong level to hold that discussion. I think the long-term solution should be to keep the registered extensions cleanly separated, and instead supply extension *groups* as a way to limit choice. -fglasgow-exts has fit that niche admirably for a long time, I think a lot of people just use that without thinking twice about what particular extensions they actually use, and nothing wrong with that. I think the move towards LANGUAGE pragmas instead of compiler options is a good one from a standardisation and implementation point of view, but to avoid tedium and unnecessary choice for the programmer I strongly feel that extension groups need to be introduced at this level too. But as I said, that's for a different discussion... > On ExistentialQuantification, I personally think we should deprecate the entire construct, suggesting GADT-style syntax instead. +1, though I was afraid to suggest something that radical. I might write a separate proposal for that then, to keep the discussion here focused on ExplicitForall. > If you can form a consensus, go for it. Alright, let's set an actual discussion period of 2 weeks for ExplicitForall. If there is no opposition by then, we can add ExplicitForall to the registered extensions in cabal as a first step. Cheers, /Niklas From bulat.ziganshin at gmail.com Wed Jun 24 08:11:09 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jun 24 07:55:54 2009 Subject: wiki page on GHC GC In-Reply-To: <4A41DF8F.6040108@gmail.com> References: <239751867.20090624012839@gmail.com> <4A41DF8F.6040108@gmail.com> Message-ID: <46645640.20090624161109@gmail.com> Hello Simon, Wednesday, June 24, 2009, 12:10:55 PM, you wrote: > You could link to the recent paper about the parallel GC, it has plenty > of information about the architecture of the GC (not just relevant to > parallel GC): > http://www.haskell.org/~simonmar/bib/parallel-gc-08_abstract.html i scanned it and it looks as more advanced reading. basically, i plan to make a "tutorial" version of basic 1993 paper plus add practical information as we talked in May one thing that isn't so good is that we lack a library of GHC-related papers. ideally, i just have to add a link to some GHC/Papers#GC that contains everything ever published about this topic. but now we have the following SPJ page (that don't yet mention paper above): http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html#gc and papers on your page that are sorted by date rather than topic i'm interested what people think about establishing GHC-related papers wiki page? it will allow to bring together papers from you, SPJ and other authors, carefully split it to topics and add more commentary without disturbing you. OTOH, it may be a waste of time since we will find not much outside of Simon&Simon pages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From claus.reinke at talk21.com Wed Jun 24 09:24:33 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jun 24 09:07:34 2009 Subject: wiki page on GHC GC References: <239751867.20090624012839@gmail.com> <4A41DF8F.6040108@gmail.com> <46645640.20090624161109@gmail.com> Message-ID: <00FE0A5B0E6B4308ABB80CCBE59AA0AD@cr3lt> > one thing that isn't so good is that we lack a library of GHC-related > papers. ideally, i just have to add a link to some GHC/Papers#GC that > contains everything ever published about this topic. http://haskell.org/haskellwiki/Research_papers#Categories http://haskell.org/haskellwiki/Research_papers/Runtime_systems#Garbage_collection http://haskell.org/haskellwiki/Research_papers/Parallelism_and_concurrency#Parallel_garbage_collection As usual, the hierarchical organisation has reached its limits, and a tag based categorisation would be more useful.. Also, generating the wiki pages from a BibTeX file, or database, for easy maintenance/referencing, would help. A long time ago, I wrote a Perl script to generate a hierarchical HTML index from BibTeX, by simply copying each entry to every category it mentioned in a tag list - these days, one would write that in Haskell, but there are online tools for similar jobs, such as citeulike.org: http://en.wikipedia.org/wiki/Citeulike So you could try selecting the references you're interested in and give them a tag that makes them easier to find http://www.citeulike.org/search/all?q=ghc+garbage has some hits, but is far from unambiguous. Claus PS There are of course, gc-specific bibliographies, such as http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbib.html http://www.cs.kent.ac.uk/people/staff/rej/cgi-bin/searchbib?pattern=haskell From allbery at ece.cmu.edu Wed Jun 24 13:30:56 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Jun 24 13:14:07 2009 Subject: finalizers on handles In-Reply-To: <4A41EC35.4000804@gmail.com> References: <4A40DB95.9050703@gmail.com><35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F1@ELON17P32001A.csfb.cs-group.com> <1D0F1BC6-DA4B-40F5-AFD4-0777750CC2BC@ece.cmu.edu> <4A41EC35.4000804@gmail.com> Message-ID: <54A12D02-B409-444D-AFBC-BE7A70BBB262@ece.cmu.edu> On Jun 24, 2009, at 05:04 , Simon Marlow wrote: > There's one exception: if GHC is forced to use blocking mode on a > particular FD, and you're using the non-threaded RTS, then a large > write using hPutBuf may block all Haskell threads. There doesn't > seem to be much we can do about this, except to use the threaded RTS > or lobby the Linux kernel guys for a better API. POSIX async IO API? (Although last I checked many distributions built kernels without it.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090624/681114c1/PGP-0001.bin From kyagrd at gmail.com Fri Jun 26 00:47:08 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Fri Jun 26 00:30:31 2009 Subject: Does this, and should this type check on GHC 6.10.x ? Message-ID: Dear GHC type hackers, We got a code (please refer to the attached lhs file) that uses type families and type classes very cleverly. We don't know who wrote itbecause this was a contribution of an anonymous reviewer on our paper, which we are still revising. http://kyagrd.dyndns.org/wiki/SharedSubtypes Although we learned a lot from this code, we still have unsolved question about this code. The problem is, we are still not sure whether this code actually type checks in any GHC version, and we are not even sure whether this should type check or not as it is. I wasn't able to type check this in any of the GHC versions 6.10.1 on windows and debian linux, GHC 6.10.2 on windows and debian linux, or GHC 6.10.3 on debian linux. I also asked some of my colleagues at my school who has GHC installed to run this code, but they weren't able to load up either. However, some people we email conversation with reported that they were able to successfully load this code in GHC version 6.10.1 in their system. This is very surprising because we weren't able to type check it with the same version (GHC 6.10.1) on our machines (Windows XP and Debian Linux). Since there is no reason that GHC type checker would behave differently among different platforms, the code I am attaching is still an unsolved misery to us. It would be very helpful for us if any of can type check this successful could report what version of GHC on what platform and what GHC command line options used to make this code type check. And also, we welcome any discussion whether this code should or should not in principle type check. Thanks in advance, Ahn, Ki Yung FYI, I had the following error message when I tried it on ghc 6.10.3. (When I commented out the problematic line, the last equation of crossB, I was able to load it up though. So, this code definitely doesn't seem to be just thought out of one's mind without actually running on ghc.) ======================================================================== kyagrd@kyavaio:~/tmp$ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.10.3 kyagrd@kyavaio:~/tmp$ ghci -fglasgow-exts -XUndecidableInstances Review3.lhs GHCi, version 6.10.3: 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 Main ( Review3.lhs, interpreted ) Review3.lhs:67:29: Could not deduce (Expandable (Tuple (Map ((,) t2) ys))) from the context (xs ~ t2 ::: ts2, Expandable t2) arising from a use of `:::' at Review3.lhs:67:29-59 Possible fix: add (Expandable (Tuple (Map ((,) t2) ys))) to the context of the constructor `:::' or add an instance declaration for (Expandable (Tuple (Map ((,) t2) ys))) In the expression: Bs (mapB x ys) ::: crossB xs ys In the definition of `crossB': crossB (x ::: xs) ys = Bs (mapB x ys) ::: crossB xs ys In the definition of `expandPair': expandPair _ pair (a ::: as) (b ::: bs) = crossB (a ::: as) (b ::: bs) where crossB :: BList xs -> BList ys -> BList (Cross xs ys) crossB Nil ys = Nil crossB (x ::: xs) ys = Bs (mapB x ys) ::: crossB xs ys mapB :: (Expandable x) => Bit x -> BList ys -> BList (Map ((,) x) ys) mapB x Nil = Nil mapB x (y ::: ys) = pair x y ::: mapB x ys Failed, modules loaded: none. -------------- next part -------------- A non-text attachment was scrubbed... Name: Review3.lhs Type: text/x-literate-haskell Size: 3728 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090626/e250b7ea/Review3.bin From allbery at ece.cmu.edu Fri Jun 26 03:30:56 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Jun 26 03:13:57 2009 Subject: Does this, and should this type check on GHC 6.10.x ? In-Reply-To: References: Message-ID: <3E0B3D04-FB28-4715-83D4-1EF7C40B1493@ece.cmu.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090626/9c58479a/PGP.bin From matthijs at stdin.nl Fri Jun 26 04:43:39 2009 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Fri Jun 26 04:26:30 2009 Subject: How unique is a Unique? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFB2D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090620171804.GW1611@katherina.student.utwente.nl> <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFB2D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20090626084339.GP1611@katherina.student.utwente.nl> Hi Simon, > The thing to read is Section 4 of: > http://research.microsoft.com/en-us/um/people/simonpj/papers/inlining/index.htm > That tells you all about the InScopeSet etc. From a first glance, it looks like you mean section 5 :-) I haven't read the paper fully yet, it's in the printer now :-) > I hope that helps. If you are still stuck after reading that, ask again. It seems like it will answer quite some questions (and its also looks like an interesting read in itself, probably even useful to cite in my thesis :-) However, one thing will probably not be answered there, since it is more of an implementation issue: Is there any function that will guarantee all Uniques in a CoreExpr will be completely unique? This is stronger than de-shadowing, since I also want Uniques in completely different branches of the expression to be different. I need this, since I want to keep a global table with a mapping from a Unique to some values (mostly related to naming). I might be able to pull this off with some hard thinking and non-unique Uniques, but it would help a lot if I didn't need to. If there isn't, I'll probably write something up (shouldn't be too hard I guess). Would there be any interest to include this in the GHC API? Or is the GHC API limited to what GHC itself uses? > Would you like to record the answers you find somewhere in the GHC > Commentary? http://hackage.haskell.org/trac/ghc/wiki/Commentary I'll see if I can write something coherent :-p. I think there might be quite a lot more I could put up there, though as always I'd need to find the time :-) Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090626/72236e5e/attachment.bin From jwlato at gmail.com Fri Jun 26 05:34:14 2009 From: jwlato at gmail.com (John Lato) Date: Fri Jun 26 05:17:02 2009 Subject: question about -fno-pre-inlining In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4B86AF58@EA-EXMSG-C334.europe.corp.microsoft.com> References: <9979e72e0906180158h54b43a0fk88e9e0fc41ba5ca6@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C33F4B86AF58@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <9979e72e0906260234v53dc02afk1e5ffb0e46b7786d@mail.gmail.com> In case anyone else was following this, I've discovered the source of the differing output. I had made some assumptions about when some code would be executed based upon faulty reasoning. Without pre-inlining those assumptions happened to hold, but they did not when pre-inlining was enabled. Thanks to Echo Nolan who independently discovered my error. Now that I've fixed this issue, the output is the same (and correct) regardless of compiler flags. It's still faster without pre-inlining, but that's a relatively minor problem in comparison. Sincerely, John On Thu, Jun 18, 2009 at 11:16 AM, Simon Peyton-Jones wrote: > John > > | When compiled with -fno-pre-inlining, my test program gives a > | different result than compiled without (0.988... :: Double, compared > | to 1.0). ?It's numerical code, and was originally compiled with > > That's entirely unexpected. I am very surprised that turning off pre-inlining > a) affects the results at all > b) improves performance > > Of course this is a floating point program, where various numeric transformations are invalid if you want bit-for-bit accuracy. ?(eg addition is not associative). ? But a 2% change seems big, unless it's a very sensitive algorithm. > > To find out what "pre-inlining" is read Section 5 of > http://research.microsoft.com/en-us/um/people/simonpj/papers/inlining/inline-jfp.ps.gz > It's called "PreInlineUnconditionally" there. > > I'm not sure how to proceed. ?The more you can boil it down, the easier it'll be to find out what is going on. ?One way to do this is to make the program smaller. But even finding out which function is sensitive to the setting of -fno-pre-inlining would be interesting. ?(You can't set this on a function by function basis, so you'll have to split the module.) > > If you can make a self-contained test case, do make a Trac ticket for it. > > Are you using the FFI? > > All very odd. > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of John Lato > | Sent: 18 June 2009 09:58 > | To: glasgow-haskell-users@haskell.org > | Subject: question about -fno-pre-inlining > | > | Hello, > | > | I was experimenting with compiler flags trying to tune some > | performance and got something unexpected with the -fno-pre-inlining > | flag. ?I was hoping somebody here might be able to clarify an issue > | for me. > | > | When compiled with -fno-pre-inlining, my test program gives a > | different result than compiled without (0.988... :: Double, compared > | to 1.0). ?It's numerical code, and was originally compiled with > | -fexcess-precision, however I have tried both with and without > | -fexcess-precision and the results are the same. ?The only other > | compiler flags in use are -O2 and --make. ?Is this expected behavior > | or a possible bug? ?I believe the value with -fno-pre-inlining is > | correct (and runs about 30% faster too). > | > | This was done on an OSX 10.5 Macbook with GHC-6.10.3. ?I could check > | this on some other systems if it would be helpful. > | > | Sincerely, > | John Lato > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From Tom.Schrijvers at cs.kuleuven.be Fri Jun 26 07:08:42 2009 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Fri Jun 26 07:02:52 2009 Subject: Does this, and should this type check on GHC 6.10.x ? In-Reply-To: References: Message-ID: > We got a code (please refer to the attached lhs file) that uses type > families and type classes very cleverly. We don't know who wrote > itbecause this was a contribution of an anonymous reviewer on our paper, > which we are still revising. http://kyagrd.dyndns.org/wiki/SharedSubtypes > Although we learned a lot from this code, we still have unsolved > question about this code. > > The problem is, we are still not sure whether this code actually type > checks in any GHC version, and we are not even sure whether this should > type check or not as it is. Have you first, before you turn to GHC< considered whether this code should be well-typed in any type system? > Review3.lhs:67:29: > Could not deduce (Expandable (Tuple (Map ((,) t2) ys))) > from the context (xs ~ t2 ::: ts2, Expandable t2) > arising from a use of `:::' at Review3.lhs:67:29-59 At first sight, it looks like this constraint Expandable (Tuple (Map ((,) t2) ys)) is indeed one that's required to hold in order to make the code well-typed. Do you agree? Yet I see no instance of Expandable for Tuple. So why do you think this constraint should hold anyway? Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From kyagrd at gmail.com Fri Jun 26 16:30:55 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Fri Jun 26 16:14:17 2009 Subject: Does this, and should this type check on GHC 6.10.x ? In-Reply-To: <24993.8501198359$1246015215@news.gmane.org> References: <24993.8501198359$1246015215@news.gmane.org> Message-ID: Tom Schrijvers wrote: > > Have you first, before you turn to GHC< considered whether this code > should be well-typed in any type system? > >> Review3.lhs:67:29: >> Could not deduce (Expandable (Tuple (Map ((,) t2) ys))) >> from the context (xs ~ t2 ::: ts2, Expandable t2) >> arising from a use of `:::' at Review3.lhs:67:29-59 > > At first sight, it looks like this constraint > > Expandable (Tuple (Map ((,) t2) ys)) > is indeed one that's required to hold in order to make the code > well-typed. Do you agree? > > Yet I see no instance of Expandable for Tuple. So why do you > think this constraint should hold anyway? I agree with you. I think the code is not supposed to type check, and that's what I experience from GHC so far. One problem that bothers us is that, as I mentioned in my original message, there were at least two reports that they were possible to type check in GHC, which we cannot reproduce. So, I'm just wondering what version and settings that makes it type check (if such version or setting exists, its good for GHC type system developers to be aware of it), and just double check if there is any other typing rules/theories that I am not aware of makes the code type check (if such version of GHC exists and it is not a bug). Another problem, which I haven't mentioned, I have when I tried to make additional type family instance declarations that latest (stable) distributions of GHC 6.10.x does not let me declare instances of (Expandable (Tuple (Map ((,) t2) ys))). When you try declaring such an instance something like this: > instance Expandable (Tuple (Map ((,) t2) ys)) where > ... GHC will give me an error message that type synonyms are not allowed in instance declarations: kyagrd@kyavaio:~/tmp$ ghci -fglasgow-exts -XUndecidableInstances Review3.lhs GHCi, version 6.10.3: 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 Main ( Review3.lhs, interpreted ) Review3.lhs:62:2: Illegal type synonym family application in instance: Tuple (Map ((,) t2) ys) In the instance declaration for `Expandable (Tuple (Map ((,) t2) ys))' Failed, modules loaded: none. So, my impression is that there is little hope even I try fixing this by adding more instance declarations, even if this was an incomplete code because of space restrictions of the review. But I still wanted to double check and discuss this matter with mailing list readers since there were few reports (which we fail to reproduce) that this type checks in their installation of GHC. From kyagrd at gmail.com Fri Jun 26 16:42:48 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Fri Jun 26 16:26:08 2009 Subject: Does this, and should this type check on GHC 6.10.x ? In-Reply-To: References: <24993.8501198359$1246015215@news.gmane.org> Message-ID: Ahn, Ki Yung wrote: > > Another problem, which I haven't mentioned, I have when I tried to make > additional type family instance declarations that latest (stable) Typo: I mean type class instance declaration of course. > distributions of GHC 6.10.x does not let me declare instances of > (Expandable (Tuple (Map ((,) t2) ys))). When you try declaring such an > instance something like this: > > > instance Expandable (Tuple (Map ((,) t2) ys)) where > > ... > > GHC will give me an error message that type synonyms are not allowed in > instance declarations: > kyagrd@kyavaio:~/tmp$ ghci -fglasgow-exts -XUndecidableInstances > Review3.lhs > GHCi, version 6.10.3: 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 Main ( Review3.lhs, interpreted ) > > Review3.lhs:62:2: > Illegal type synonym family application in instance: > Tuple (Map ((,) t2) ys) > In the instance declaration for `Expandable (Tuple (Map ((,) t2) ys))' > Failed, modules loaded: none. > > So, my impression is that there is little hope even I try fixing this by > adding more instance declarations, even if this was an incomplete code > because of space restrictions of the review. But I still wanted to > double check and discuss this matter with mailing list readers since > there were few reports (which we fail to reproduce) that this type > checks in their installation of GHC. From niklas.broberg at gmail.com Sat Jun 27 06:44:49 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Jun 27 06:27:34 2009 Subject: Proposal: Deprecate ExistentialQuantification Message-ID: 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 From batterseapower at hotmail.com Sat Jun 27 06:52:53 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Jun 27 06:35:39 2009 Subject: group keyword with TransformListComp In-Reply-To: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> References: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> Message-ID: <9d4d38820906270352id1d3609ye72c81cce899a45e@mail.gmail.com> 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 : > 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 > From aslatter at gmail.com Sat Jun 27 10:34:34 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sat Jun 27 10:17:20 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <694519c50906270734l216540ebhc91840367f9860df@mail.gmail.com> On Sat, Jun 27, 2009 at 5:44 AM, Niklas Broberg wrote: > 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. How does the support of the extensions differ between existing implementations? Antoine From ml at isaac.cedarswampstudios.org Sat Jun 27 10:51:12 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Jun 27 10:34:16 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <4A4631E0.7070201@isaac.cedarswampstudios.org> Niklas Broberg wrote: > 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 > 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. Is it easy algorithmically to look at a GADT and decide whether it has only ExistentialQuantification features? After all, IIRC, hugs and nhc support ExistentialQuantification but their type systems might not be up to the full generality of GADTs. (GHC's wasn't even quite up to it for quite a long time until around 6.8, when we finally got it right.) -Isaac From malcolm.wallace at cs.york.ac.uk Sat Jun 27 14:55:30 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat Jun 27 14:38:18 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <98F04925-50ED-43C0-8C85-FCD54A0FB513@cs.york.ac.uk> > I would hereby like to propose that the > ExistentialQuantification extension is deprecated. It is worth pointing out that all current Haskell implementations (to my knowledge) have ExistentialQuantification, whilst there is only one Haskell implementation that has the proposed replacement feature, GADTs. Of course, that in itself is not an argument to avoid desirable change to the language, but it is one factor to consider. Regards, Malcolm From niklas.broberg at gmail.com Sat Jun 27 15:37:30 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Jun 27 15:20:14 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <98F04925-50ED-43C0-8C85-FCD54A0FB513@cs.york.ac.uk> References: <98F04925-50ED-43C0-8C85-FCD54A0FB513@cs.york.ac.uk> Message-ID: >> I would hereby like to propose that the >> ExistentialQuantification extension is deprecated. > > It is worth pointing out that all current Haskell implementations (to my > knowledge) have ExistentialQuantification, whilst there is only one Haskell > implementation that has the proposed replacement feature, GADTs. > > Of course, that in itself is not an argument to avoid desirable change to > the language, but it is one factor to consider. The tongue-in-cheek response is that it should be a factor to consider only for how long a deprecation period we want... ;-) Seriously though, it's of course a consideration that should be made. It also ties back to the problem of the monolithic GADTs extension, which isn't trivial to implement in other tools - but the ExistentialQuantification *subset* of GADTs should be easy, for any implementation that already supports the current ExistentialQuantification extension, since then it's just a syntactic issue. So might as well bite that bullet then, what if we did the following split, in the spirit of the various increasing power of the extensions that enable forall-quantified types ((ExplicitForall <=) PolymorphicComponents <= Rank2Types <= RankNTypes): * NewConstructorSyntax: Lets the programmer write data types using the GADTs *syntax*, but doesn't add any type-level power (and no forall syntax). Could probably use a better name (bikeshed warning). * ExistentialQuantification: Implies NewConstructorSyntax (and ExplicitForall). Let's the programmer use existentially quantified arguments to constructors when using the GADTs syntax. Still requires all constructors to have the same type, which is the one given in the header. * GADTs: Implies ExistentialQuantification. Let's the programmer use the full type-level power of GADTs. It might make sense to merge NewConstructorSyntax and ExistentialQuantification, though I'm not sure naming that merge ExistentialQuantification would be accurate (naming is the bikeshed though). Personally I would prefer the full 3-way split, to keep a clean separation between syntactic and semantic extensions, but it's a rather weak preference. If we had something like this split, implementations that already support ExistentialQuantification at the type level would "only" need to change their parsers in a simple way (nothing hard, trust me), and add what should be a simple check that the constructors all have the declared type. Would that be preferable? Cheers, /Niklas From allbery at ece.cmu.edu Sat Jun 27 16:41:56 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Jun 27 16:24:56 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <98F04925-50ED-43C0-8C85-FCD54A0FB513@cs.york.ac.uk> Message-ID: <15D137EE-8F18-4354-ACAE-1922E738B424@ece.cmu.edu> On Jun 27, 2009, at 15:37 , Niklas Broberg wrote: > * NewConstructorSyntax: Lets the programmer write data types using the > GADTs *syntax*, but doesn't add any type-level power (and no forall > syntax). Could probably use a better name (bikeshed warning). GeneralizedTypeSyntax occurs to me. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090627/d1b4fd96/PGP.bin From stefan at cs.uu.nl Sun Jun 28 03:43:16 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 03:25:59 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: Niklas, > 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. That's why one should really be allowed to group constructor's in a type's definition: data Colour :: * where Red, Green, Blue :: Colour This is consistent with what is allowed for type signatures for functions. More general, whatever way your proposal is going, I think you should have it reflect that there are two, more or less unrelated, issues here: 1. The expressiveness of data types: algebraic data types < existential data types < GADTs. 2. The syntax of type definitions: the classic, Haskell 98 syntax and the new, cool listings-of-constructor-signature syntax. (Don't call the latter NewTypeSyntax or anything similar in a LANGUAGE pragma; choose something descriptive.) These are really orthogonal issues: all three levels of expressiveness of types can be expressed in either syntax. Therefore: keep these issues separated in your proposal. Just my two cents, Stefan From john at repetae.net Sun Jun 28 04:35:06 2009 From: john at repetae.net (John Meacham) Date: Sun Jun 28 04:17:53 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <4A4631E0.7070201@isaac.cedarswampstudios.org> References: <4A4631E0.7070201@isaac.cedarswampstudios.org> Message-ID: <20090628083505.GB22067@sliver.repetae.net> On Sat, Jun 27, 2009 at 10:51:12AM -0400, Isaac Dupree wrote: > Niklas Broberg wrote: >> 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 > >> 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. > > Is it easy algorithmically to look at a GADT and decide whether it has > only ExistentialQuantification features? After all, IIRC, hugs and nhc > support ExistentialQuantification but their type systems might not be up > to the full generality of GADTs. (GHC's wasn't even quite up to it for > quite a long time until around 6.8, when we finally got it right.) Jhc also supports ExistentialQuantification but not full GADTs. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From niklas.broberg at gmail.com Sun Jun 28 06:17:08 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 05:59:50 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: > That's why one should really be allowed to group constructor's in a type's > definition: > > ?data Colour :: * where > ? ?Red, Green, Blue :: Colour > > This is consistent with what is allowed for type signatures for functions. Totally agreed, and that should be rather trivial to implement too. > More general, whatever way your proposal is going, I think you should have > it reflect that there are two, more or less unrelated, issues here: > > 1. The expressiveness of data types: algebraic data types < existential data > types < GADTs. > 2. The syntax of type definitions: the classic, Haskell 98 syntax and the > new, cool listings-of-constructor-signature syntax. (Don't call the latter > NewTypeSyntax or anything similar in a LANGUAGE pragma; choose something > descriptive.) > > These are really orthogonal issues: all three levels of expressiveness of > types can be expressed in either syntax. Therefore: keep these issues > separated in your proposal. Well, I think my proposal already does reflect this fact, if implicitly. The point of the proposal is that all three levels of expressiveness of types can be expressed in the listings-of-constructor-signature syntax, but to express the type level power of existential data types or GADTs with the classic syntax, we need to extend that syntax. And that's what I'm after, that's we remove this rather ad-hoc add on syntax required to express existential quantification with classic constructor declarations. In other words, in your 2x3 grid of syntactic x expressiveness, I want the two points corresponding to classic syntax x {existential quantification, GADTs} to be removed from the language. My second semi-proposal also makes each of the three points corresponding to the new cool syntax a separate extension. Cheers, /Niklas From stefan at cs.uu.nl Sun Jun 28 06:23:24 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 06:06:07 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Niklas, > In other words, in your 2x3 grid of syntactic x expressiveness, I want > the two points corresponding to classic syntax x {existential > quantification, GADTs} to be removed from the language. My second > semi-proposal also makes each of the three points corresponding to the > new cool syntax a separate extension. I see, but why are you opposed to have the classic syntax still support existentials (though foralls) and GADTs (through equality constraints). I would make sense to me to keep this support around. Cheers, Stefan From niklas.broberg at gmail.com Sun Jun 28 06:32:47 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 06:15:29 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: >> In other words, in your 2x3 grid of syntactic x expressiveness, I want >> the two points corresponding to classic syntax x {existential >> quantification, GADTs} to be removed from the language. My second >> semi-proposal also makes each of the three points corresponding to the >> new cool syntax a separate extension. > > I see, but why are you opposed to have the classic syntax still support > existentials (though foralls) and GADTs (through equality constraints). I > would make sense to me to keep this support around. I am opposed since a) it requires the addition of extra syntax to the language, and b) we have another, better, way to do it. Somewhat pointed, I don't think the C++ way of putting all imaginable ways to do the same thing into the language is a sound design principle. If we have two ways to do the same thing, and one of them is considered prefered, then I see no reason at all to keep the other around. What I'm arguing here is that the GADT style syntax is truly preferable, and thus the other should be removed. Cheers, /Niklas From stefan at cs.uu.nl Sun Jun 28 06:47:28 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 06:30:22 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: Niklas, > I am opposed since > a) it requires the addition of extra syntax to the language, and > b) we have another, better, way to do it. > > Somewhat pointed, I don't think the C++ way of putting all imaginable > ways to do the same thing into the language is a sound design > principle. If we have two ways to do the same thing, and one of them > is considered prefered, then I see no reason at all to keep the other > around. What I'm arguing here is that the GADT style syntax is truly > preferable, and thus the other should be removed. I agree. But ;-) since it's obvious not possible to get rid of the classic syntax completely, I see no harm in having it support existentials and GADTs as well. In an ideal word, in which there wasn't a single Haskell program written yet, I'd indeed like to throw the classic syntax out altogether. Cheers, Stefan On Jun 28, 2009, at 12:32 PM, Niklas Broberg wrote: >>> In other words, in your 2x3 grid of syntactic x expressiveness, I >>> want >>> the two points corresponding to classic syntax x {existential >>> quantification, GADTs} to be removed from the language. My second >>> semi-proposal also makes each of the three points corresponding to >>> the >>> new cool syntax a separate extension. >> >> I see, but why are you opposed to have the classic syntax still >> support >> existentials (though foralls) and GADTs (through equality >> constraints). I >> would make sense to me to keep this support around. > > I am opposed since > a) it requires the addition of extra syntax to the language, and > b) we have another, better, way to do it. > > Somewhat pointed, I don't think the C++ way of putting all imaginable > ways to do the same thing into the language is a sound design > principle. If we have two ways to do the same thing, and one of them > is considered prefered, then I see no reason at all to keep the other > around. What I'm arguing here is that the GADT style syntax is truly > preferable, and thus the other should be removed. > > Cheers, > > /Niklas From niklas.broberg at gmail.com Sun Jun 28 07:17:20 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 07:00:02 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: > I agree. But ;-) since it's obvious not possible to get rid of the classic > syntax completely, I see no harm in having it support existentials and GADTs > as well. In an ideal word, in which there wasn't a single Haskell program > written yet, I'd indeed like to throw the classic syntax out altogether. Ah, but there's the thing. The classic syntax *doesn't* support existentials and GADTs, if by classic you mean Haskell 98. You need a separate syntactic extension, and the one we have is ad-hoc and unintuitive (the whole universal vs existential quantification thing is awkward), not to mention ugly. There's simply no sense to a declaration reading e.g. > data Foo = forall a . (Show a) => Foo a The entities on the right-hand side of that declaration come in the wrong order, intuitively. What you really want or mean when you use the classic syntax with existential quantification is > data Foo = Foo (exists a . (Show a) => a) Having that would make a lot more sense, and would fit well together with the intuition of the classic syntax. If we wanted to keep support for existential quantification together with the classic style, that should IMNSHO be the way to do it. But for various reasons (like not wanting to steal another keyword) we don't do it that way. Instead we have a syntax that is meant to be understood as "constructor Foo has the type forall a . (Show a) => a". But that's exactly what we would express with the GADT-style syntax! :-) Cheers, /Niklas From niklas.broberg at gmail.com Sun Jun 28 07:19:16 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 07:01:59 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: > ... "constructor Foo has the type forall a . (Show a) => a". Eh, of course I meant "the type forall a . (Show a) => a -> Foo", but you understood that I'm sure. :-) Cheers, /Niklas From stefan at cs.uu.nl Sun Jun 28 07:24:53 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 07:07:36 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: <92F5A2B7-E022-46F6-9CE5-119D30D113C1@cs.uu.nl> Niklas, > What you really want or mean when you use > the classic syntax with existential quantification is > >> data Foo = Foo (exists a . (Show a) => a) > > Having that would make a lot more sense, and would fit well together > with the intuition of the classic syntax. How would you then define data Foo :: * where Foo :: forall a. a -> a -> Foo in which the scope of existentially quantified type variable spans more than one field? Cheers, Stefan From niklas.broberg at gmail.com Sun Jun 28 07:31:22 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 07:14:05 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <92F5A2B7-E022-46F6-9CE5-119D30D113C1@cs.uu.nl> References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> <92F5A2B7-E022-46F6-9CE5-119D30D113C1@cs.uu.nl> Message-ID: >> What you really want or mean when you use >> the classic syntax with existential quantification is >> >>> data Foo = Foo (exists a . (Show a) => a) >> >> Having that would make a lot more sense, and would fit well together >> with the intuition of the classic syntax. > > How would you then define > > ?data Foo :: * where > ? ?Foo :: forall a. a -> a -> Foo > > in which the scope of existentially quantified type variable spans more than > one field? Good point, and one I admit I hadn't considered. Using GADT style syntax? ;-) However, your argument certainly speaks against the style using exists, but it doesn't do much to persuade me that the style we now have is any less of a wart. To me it's just another point in favor of deprecating it with the classic syntax completely. Cheers, /Niklas From simonpj at microsoft.com Mon Jun 29 03:42:02 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 29 03:24:44 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3439152691B@EA-EXMSG-C334.europe.corp.microsoft.com> | That's why one should really be allowed to group constructor's in a | type's definition: | | data Colour :: * where | Red, Green, Blue :: Colour Indeed. GHC allows this now. (HEAD only; will be in 6.12.) Simon From simonpj at microsoft.com Mon Jun 29 04:14:29 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 29 03:57:10 2009 Subject: How unique is a Unique? In-Reply-To: <20090626084339.GP1611@katherina.student.utwente.nl> References: <20090620171804.GW1611@katherina.student.utwente.nl> <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFB2D@EA-EXMSG-C334.europe.corp.microsoft.com> <20090626084339.GP1611@katherina.student.utwente.nl> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C34391526968@EA-EXMSG-C334.europe.corp.microsoft.com> | However, one thing will probably not be answered there, since it is more of an | implementation issue: Is there any function that will guarantee all Uniques in | a CoreExpr will be completely unique? This is stronger than de-shadowing, | since I also want Uniques in completely different branches of the expression | to be different. Not at the moment. | I need this, since I want to keep a global table with a mapping from a Unique | to some values (mostly related to naming). I might be able to pull this off | with some hard thinking and non-unique Uniques, but it would help a lot if I | didn't need to. | | If there isn't, I'll probably write something up (shouldn't be too hard I | guess). Would there be any interest to include this in the GHC API? Or is the | GHC API limited to what GHC itself uses? I think the best way would be to make a new package that depends on the GHC package. That's what Cabal is so good for! Simon From marlowsd at gmail.com Mon Jun 29 07:32:28 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 29 07:15:10 2009 Subject: finalizers on handles In-Reply-To: <54A12D02-B409-444D-AFBC-BE7A70BBB262@ece.cmu.edu> References: <4A40DB95.9050703@gmail.com><35C68040-311B-4567-A146-7C5A9BCBE101@ece.cmu.edu> <72B62674-CD28-428C-8E4E-5146674CC074@ece.cmu.edu> <16442B752A06A74AB4D9F9A5FF076E4B03B9F6F1@ELON17P32001A.csfb.cs-group.com> <1D0F1BC6-DA4B-40F5-AFD4-0777750CC2BC@ece.cmu.edu> <4A41EC35.4000804@gmail.com> <54A12D02-B409-444D-AFBC-BE7A70BBB262@ece.cmu.edu> Message-ID: <4A48A64C.6060007@gmail.com> On 24/06/2009 18:30, Brandon S. Allbery KF8NH wrote: > On Jun 24, 2009, at 05:04 , Simon Marlow wrote: >> There's one exception: if GHC is forced to use blocking mode on a >> particular FD, and you're using the non-threaded RTS, then a large >> write using hPutBuf may block all Haskell threads. There doesn't seem >> to be much we can do about this, except to use the threaded RTS or >> lobby the Linux kernel guys for a better API. > > > POSIX async IO API? (Although last I checked many distributions built > kernels without it.) Yes, that would solve the problem, if it was available. Cheers, Simon From ndmitchell at gmail.com Mon Jun 29 15:58:54 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 29 15:41:33 2009 Subject: group keyword with TransformListComp In-Reply-To: <9d4d38820906270352h2e5d3912peaff0ddd8363fa32@mail.gmail.com> References: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> <9d4d38820906270352h2e5d3912peaff0ddd8363fa32@mail.gmail.com> Message-ID: <404396ef0906291258t2c905803mbc88af8943c62c79@mail.gmail.com> 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 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 : >> 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 >> > From simonpj at microsoft.com Tue Jun 30 03:00:53 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 30 02:43:39 2009 Subject: group keyword with TransformListComp In-Reply-To: <404396ef0906291258t2c905803mbc88af8943c62c79@mail.gmail.com> References: <404396ef0906211114q54fec0ebo4ec20519698eb5cd@mail.gmail.com> <9d4d38820906270352h2e5d3912peaff0ddd8363fa32@mail.gmail.com> <404396ef0906291258t2c905803mbc88af8943c62c79@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3439152705A@EA-EXMSG-C334.europe.corp.microsoft.com> I agree it's undesirable. It would be great if someone could lead a discussion leading to a better alternative. Perhaps the same process that we use for libraries would be appropriate here. http://www.haskell.org/haskellwiki/Library_submissions Namely: make a proposal, give an expiry date, lead discussion. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Neil Mitchell | Sent: 29 June 2009 20:59 | To: Max Bolingbroke | Cc: glasgow-haskell-users@haskell.org | Subject: Re: group keyword with TransformListComp | | 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 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 : | >> 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 | >> | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Tue Jun 30 06:14:20 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 30 05:57:07 2009 Subject: 6.12.1 planning Message-ID: <4A49E57C.6070602@gmail.com> 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 . * 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=reopened&milestone=6.12.1 and on the 6.12 branch (251): http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.12+branch 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 From simonpj at microsoft.com Tue Jun 30 09:45:03 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jun 30 09:27:41 2009 Subject: 6.12.1 planning In-Reply-To: <4A49E57C.6070602@gmail.com> References: <4A49E57C.6070602@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C34391527452@EA-EXMSG-C334.europe.corp.microsoft.com> I've dumped all this on a release plans wiki page: http://hackage.haskell.org/trac/ghc/wiki/Status/Releases Manuel, Duncan: maybe you can modify the wiki directly? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 30 June 2009 11:14 | To: glasgow-haskell-users@haskell.org | Cc: Manuel M T Chakravarty; Duncan Coutts; Haskell Cafe | Subject: 6.12.1 planning | | 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! From duncan.coutts at worc.ox.ac.uk Tue Jun 30 18:09:52 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jun 30 18:39:55 2009 Subject: 6.12.1 planning In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C34391527452@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4A49E57C.6070602@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C34391527452@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1246399792.28197.1625.camel@localhost> On Tue, 2009-06-30 at 14:45 +0100, Simon Peyton-Jones wrote: > I've dumped all this on a release plans wiki page: > http://hackage.haskell.org/trac/ghc/wiki/Status/Releases > > Manuel, Duncan: maybe you can modify the wiki directly? Done. Fortunately there's not much left to do for shared libs, at least on Linux. Duncan From iainspeed at gmail.com Tue Jun 30 19:11:44 2009 From: iainspeed at gmail.com (Iain Barnett) Date: Tue Jun 30 18:54:18 2009 Subject: Fwd: exposing hidden packages with runghc In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090630/09b4f270/attachment.html From daniel.is.fischer at web.de Tue Jun 30 19:56:39 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Jun 30 19:40:11 2009 Subject: Fwd: exposing hidden packages with runghc In-Reply-To: References: Message-ID: <200907010156.39542.daniel.is.fischer@web.de> Am Mittwoch 01 Juli 2009 01:11:44 schrieb Iain Barnett: > 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. In the 6.8 series, the base package was split up. Prior to that, the Array modules were part of base. HTTP-3000.0.0 seems to be from before 6.8, so it doesn't list the array package among its build dependencies. Cabal hides all packages which aren't listed when building a library. Quick fix: add array to the build dependencies in the .cabal file. But why are you trying to build such an outdated cabal-install? > > 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