From georg.martius at web.de Wed Aug 1 03:42:54 2007 From: georg.martius at web.de (Georg Martius) Date: Wed Aug 1 03:35:16 2007 Subject: Annotation for unfolding wanted In-Reply-To: References: <200707301609.26276.georg.martius@web.de> <200707311552.57054.georg.martius@web.de> Message-ID: <200708010942.59069.georg.martius@web.de> Hi, I am sorry for using the wrong terminology here. Let me ask again: Does it sound reasonable to extend the compiler with a pragma that specifies that a certain function should be compiled to a loop? And if the compiler can not do it, it helps with some error message. Regards! Georg On Tuesday 31 July 2007 16:20, Simon Peyton-Jones wrote: > | However my point was more on a semantic point of view: If I write a > | function in a recursive way, but actually do nothing else than a loop, I > | would like a) that the compiler unrolls it to a loop and > | b) that I can specify such a requirement, while violating it emits an > | error. > > What does it mean to say "the compiler unrolls it to a loop". If GHC sees > a tail recursive function, it certainly compiles it to a loop! (But that's > not called "unrolling".) > > Simon -- ---- Georg Martius, Tel: +49 177 6413311 ----- ------- http://www.flexman.homeip.net ---------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070801/821bb1f8/attachment.bin From stefanor at cox.net Wed Aug 1 03:56:04 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Aug 1 03:48:30 2007 Subject: Annotation for unfolding wanted In-Reply-To: <200708010942.59069.georg.martius@web.de> References: <200707301609.26276.georg.martius@web.de> <200707311552.57054.georg.martius@web.de> <200708010942.59069.georg.martius@web.de> Message-ID: <20070801075604.GA6485@localhost.localdomain> On Wed, Aug 01, 2007 at 09:42:54AM +0200, Georg Martius wrote: > Hi, > > I am sorry for using the wrong terminology here. Let me ask again: > Does it sound reasonable to extend the compiler with a pragma that specifies > that a certain function should be compiled to a loop? And if the compiler can > not do it, it helps with some error message. Unfortunately, that's still almost useless in the presence of laziness. Take the following (contrived) example: fib :: Int -> (Int,Int) -> (Int,Int) fib 0 p = p fib k p = fib (k-1) (snd p, fst p + snd p) That compiles to a perfectly reasonable loop: (minor code rearrangement and bounds-checks deleted for clarity) X_zdszdwfib_info: Hp = Hp + 16; _sjD = I32[Sp + 8]; if (_sjD == 0) goto clk; _sjF = _sjD - 1; I32[Hp - 12] = sjC_info; I32[Hp - 4] = I32[Sp + 4]; I32[Hp] = I32[Sp]; I32[Sp + 8] = _sjF; I32[Sp + 4] = I32[Sp]; I32[Sp] = Hp - 12; jump X_zdszdwfib_info (); clk: I32[Hp - 12] = base_DataziTuple_Z2T_con_info; I32[Hp - 8] = I32[Sp + 4]; I32[Hp - 4] = I32[Sp]; R1 = Hp - 12; Sp = Sp + 12; Hp = Hp - 4; jump I32[Sp] (); Yet still: Prelude X> fib 10000000 (1,1) (*** Exception: stack overflow Since while *your function* may be a loop, the thunks it builds are evaluated in a way that isn't. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070801/626fa7c8/attachment.bin From simonpj at microsoft.com Wed Aug 1 04:06:10 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Aug 1 03:58:32 2007 Subject: Annotation for unfolding wanted In-Reply-To: <200708010942.59069.georg.martius@web.de> References: <200707301609.26276.georg.martius@web.de> <200707311552.57054.georg.martius@web.de> <200708010942.59069.georg.martius@web.de> Message-ID: If it's tail recursive it'll be compiled to a loop. You don't need a pragma. Of course if it does evaluation along the way, it'll have to make a call do to that evaluation. E.g. f x = if x>0 then 0 else f (g x) Here f is tail-rec but it'll have to call g inside the loop. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Georg Martius | Sent: 01 August 2007 08:43 | To: Simon Peyton-Jones; Glasgow-haskell-users@haskell.org | Subject: Re: Annotation for unfolding wanted | | Hi, | | I am sorry for using the wrong terminology here. Let me ask again: | Does it sound reasonable to extend the compiler with a pragma that specifies | that a certain function should be compiled to a loop? And if the compiler can | not do it, it helps with some error message. | | Regards! | Georg | | On Tuesday 31 July 2007 16:20, Simon Peyton-Jones wrote: | > | However my point was more on a semantic point of view: If I write a | > | function in a recursive way, but actually do nothing else than a loop, I | > | would like a) that the compiler unrolls it to a loop and | > | b) that I can specify such a requirement, while violating it emits an | > | error. | > | > What does it mean to say "the compiler unrolls it to a loop". If GHC sees | > a tail recursive function, it certainly compiles it to a loop! (But that's | > not called "unrolling".) | > | > Simon | | -- | ---- Georg Martius, Tel: +49 177 6413311 ----- | ------- http://www.flexman.homeip.net ---------- From claus.reinke at talk21.com Wed Aug 1 08:37:21 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Aug 1 08:29:46 2007 Subject: Annotation for unfolding wanted References: <200707301609.26276.georg.martius@web.de> Message-ID: <011501c7d438$b6061ee0$933b8351@cr3lt> >Some compilers unroll recursive functions by inlining them N times, for some fixed N (say 3 or so). >This reduces the loop overheads. GHC doesn't do this, although it'd be nice, because it makes >repeated traversals of the code, and it's hard to spot when the function has been unrolled 3 times >and then stop. If you look at the code after unrolling 3 times, from scratch, there's another call >just waiting to be inlined. couldn't the number of unfoldings be encoded in the name of the function? f x = if p x then x else f (g x) f x = if p x then x else let x' = (g x) in if p x' then x' else f#1 (g x') where f#1 would be f for all other purposes, but with one unfolding used up, and N being the bound for the f#i. claus From cperfumo at gmail.com Thu Aug 2 04:59:12 2007 From: cperfumo at gmail.com (Cristian Perfumo) Date: Thu Aug 2 04:51:30 2007 Subject: Ticky Ticky profiling In-Reply-To: <4683d9370707311548s7bcffa0el4f711afe4c66a432@mail.gmail.com> References: <4683d9370707311548s7bcffa0el4f711afe4c66a432@mail.gmail.com> Message-ID: By the way... does ticky-ticky allow monitoring multithreaded programs? I ask this because the other way of learning data about the execution (compiling with -prof) is not compatible with -threaded options. In other words, you can't compile a Haskell program with -prof and -threaded options at the same time. Cheers. Cristian On 8/1/07, Tim Chevalier wrote: > > On 7/31/07, Cristian Perfumo wrote: > > Hi all!. > > I modified build.mk in order to allow Ticky-Ticky profiling > (GhcLibWays=t). Now, when I try to make I get this error: > > > > ------------------------------------------------------------------------ > > > > == make way=t all; > > PWD = (the_whole_path)/ghc-6.6.1/rts > > ------------------------------------------------------------------------ > > ../compiler/ghc-inplace -H32m -O -fasm -W -fno-warn-unused-matches > -fwarn-unused-imports -optc-O2 -static -I. -#include > > HCIncludes.h -fvia-C -dcmm-lint -hisuf t_hi -hcsuf t_hc -osuf t_o > -ticky -#include posix/Itimer.h -c PrimOps.cmm -o PrimOps.t_o > > ghc-6.6.1: panic! (the 'impossible' happened) > > (GHC version 6.6.1 for i386-unknown-linux): > > > > ToDo: tickyAllocThunk > > > > Hi, Cristian-- > To get ticky to work, you need the HEAD (or a recent nightly build > snapshot). If it's still not working after that, post again. > > Cheers, > Tim > > -- > Tim Chevalier* catamorphism.org *Often in error, never in doubt > "More than at any other time in history, mankind faces a crossroads. > One path leads to despair and utter hopelessness. The other, to total > extinction. Let us pray we have the wisdom to choose > correctly."--Woody Allen > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070802/f1c96083/attachment.htm From stefanor at cox.net Thu Aug 2 12:18:07 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Aug 2 12:10:25 2007 Subject: Ticky Ticky profiling In-Reply-To: References: <4683d9370707311548s7bcffa0el4f711afe4c66a432@mail.gmail.com> Message-ID: <20070802161807.GA3244@localhost.localdomain> On Thu, Aug 02, 2007 at 10:59:12AM +0200, Cristian Perfumo wrote: > By the way... does ticky-ticky allow monitoring multithreaded programs? > I ask this because the other way of learning data about the execution > (compiling with -prof) is not compatible with -threaded options. In other > words, you can't compile a Haskell program with -prof and -threaded options > at the same time. You don't need -threaded to run multithreaded programs. -threaded will make them run *faster* on >1-core machines, but the normal RTS will run multiple Haskell threads just fine on its single OS-thread. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070802/31f9ed7c/attachment.bin From cperfumo at gmail.com Thu Aug 2 12:43:02 2007 From: cperfumo at gmail.com (Cristian Perfumo) Date: Thu Aug 2 12:35:18 2007 Subject: Ticky Ticky profiling In-Reply-To: <20070802161807.GA3244@localhost.localdomain> References: <4683d9370707311548s7bcffa0el4f711afe4c66a432@mail.gmail.com> <20070802161807.GA3244@localhost.localdomain> Message-ID: Sorry, It looks like I haven't been precise with my question: I wanted to say multiple hardware (it implies OS) threads. In other words: are -threaded and ticky ticky compatible? Will I be able to run "./myProgram +RTS -N4 -rmyout.ticky" ? Hope my doubt is clearer now. Regards. Cristian On 8/2/07, Stefan O'Rear wrote: > > On Thu, Aug 02, 2007 at 10:59:12AM +0200, Cristian Perfumo wrote: > > By the way... does ticky-ticky allow monitoring multithreaded programs? > > I ask this because the other way of learning data about the execution > > (compiling with -prof) is not compatible with -threaded options. In > other > > words, you can't compile a Haskell program with -prof and -threaded > options > > at the same time. > > You don't need -threaded to run multithreaded programs. > > -threaded will make them run *faster* on >1-core machines, but the > normal RTS will run multiple Haskell threads just fine on its single > OS-thread. > > Stefan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGsgO/FBz7OZ2P+dIRAjI4AKCXDt9A87auA57GlKYm0CGk4sp9OQCaA3qk > LSAmbXi/iCpiRC96ZpSz4KY= > =1WKQ > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070802/621dc174/attachment-0001.htm From kolmodin at dtek.chalmers.se Thu Aug 2 14:24:53 2007 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Thu Aug 2 14:17:11 2007 Subject: ghc-pkg bash completion Message-ID: <46B22175.2070006@dtek.chalmers.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all! I wrote a bash completion to ghc-pkg last year, just cleaned it up a bit and thought I should share it with you guys. You get your copy by typing: ; darcs get http://haskell.org/~kolmodin/code/ghc-bash-completion/ Then, to load it (quick'n'dirty without proper install): ; cd ghc-bash-completion ; source ./ghc-pkg ; source ./ghci A session could look like: ; ghc-pkg # hit the tab key twice. # it gives your valid options - --auto-ghci-libs --package-conf= -V hide - --define-name= --simple-output -f latest - --force --user -g list - --global --version describe register - --global-conf= -? expose unregister - --help -D field update ; ghc-pkg hide # gives you a list of # packages and optional flags The ghci support is very minimalistic at this point... it only completes on packages. That's it! Cheers, Lennart -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsiF14txYG4KUCuERAnxMAJ4nzs8UPrNGevihKKVdSnsyOy3+twCgqQ0J itCHvhD13LEE88UBjBsmXmA= =Sndh -----END PGP SIGNATURE----- From catamorphism at gmail.com Thu Aug 2 16:48:13 2007 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Aug 2 16:40:30 2007 Subject: Ticky Ticky profiling In-Reply-To: References: <4683d9370707311548s7bcffa0el4f711afe4c66a432@mail.gmail.com> <20070802161807.GA3244@localhost.localdomain> Message-ID: <4683d9370708021348n1c697944we9d012bcc1b787bc@mail.gmail.com> On 8/2/07, Cristian Perfumo wrote: > Sorry, It looks like I haven't been precise with my question: I wanted to > say multiple hardware (it implies OS) threads. > In other words: are -threaded and ticky ticky compatible? Will I be able to > run "./myProgram +RTS -N4 - rmyout.ticky" ? I haven't tried it, but the best way to find out is to try it and see :-) If you run into problems, yell. Cheers, Tim -- Tim Chevalier * chevalier@alum.wellesley.edu * Often in error, never in doubt From catamorphism at gmail.com Thu Aug 2 21:09:04 2007 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Aug 2 21:01:20 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) Message-ID: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> I'm forwarding this to ghc-users since nobody answered on haskell-cafe, and I'm still curious... (The original message is at http://www.nabble.com/Lazy-in-either-argument--t4133855.html) ---------- Forwarded message ---------- From: Tim Chevalier Date: Jul 26, 2007 4:52 PM Subject: Re: [Haskell-cafe] Lazy in either argument? To: Lennart Augustsson Cc: Dan Weston , haskell-cafe On 7/26/07, Lennart Augustsson wrote: > The non-termination is (probably) due to the fact that you can have uninterruptible threads in ghc. > If a thread never allocates it will never be preempted. :( > To elaborate on that, the different behavior between the two versions of Dan's code, one with and one without a type signature, happens because f compiles like so if the type signature isn't given (this is the STG code): f_ri5 = \u [] let-no-escape { f1_sPY = NO_CCS[] \u [] f1_sPY; } in f1_sPY; SRT(f_ri5): [] and like so if the type signature is given: f_ri5 = \u srt:(0,*bitmap*) [] f_ri5; SRT(f_ri5): [f_ri5] If you look at the resulting asm code, the second version of f_ri5 compiles to a loop that allocates on each iteration, whereas the body of the let in the first version of f_ri5 compiles to just: sPY_info: jmp sPY_info (Adding f to the export list so that its SRT is empty doesn't change anything, btw.) This is all with -Onot. So I find this a little confusing. Why is f = let f_1 = f_1 in f_1 compiled so differently from f = f? It seems like f = f should also compile to a loop that doesn't allocate anything. And from the user's perspective, it seems somewhat strange that adding or removing a type signature changes the semantics of their code (although I guess you could make the argument that if you're dealing with threads and nonterminating code, all bets are off.) Can someone better acquainted with the code generator than me explain the rationale behind this? Cheers, Tim -- Tim Chevalier* catamorphism.org *Often in error, never in doubt "Religion is just a fancy word for the Stockholm Syndrome." -- lj user="pure_agnostic" From catamorphism at gmail.com Thu Aug 2 21:26:36 2007 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Aug 2 21:18:51 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> Message-ID: <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> On 8/2/07, Tim Chevalier wrote: > I'm forwarding this to ghc-users since nobody answered on > haskell-cafe, and I'm still curious... (The original message is at > http://www.nabble.com/Lazy-in-either-argument--t4133855.html) > Replying to myself again, I figured out later that what's really going on in this example is that when you write: f = f (with no type signature) it desugars to: f = \@a -> let f' = f' in f' whereas if you write: f :: Bool f = f the code is left more or less as is (if you're compiling with -Onot). Then the let-body in the unannotated version gets compiled to a loop that doesn't allocate, whereas (and I don't quite follow why) the definition in the annotated version gets compiled to a loop that allocates a new closure on each iteration. Thus, in the example with two threads, the second version will be pre-empted to run the other thread that does terminate, whereas the first version will never be pre-empted. This makes sense at least if you consider the desugaring of polymorphic definitions separately from the semantics of threads... it's only when they interact that something strange happens. Maybe it's an extreme corner case, but it still seems weird to me that adding or removing a type signature should change the semantics of code like this. It seems to me like the problem is that that the transformation from (f = f) to (f = let f' = f' in f') isn't valid in the presence of threads, since in a multithreaded situation the two are observably different... but is that a bug in the desugarer, or a bug in GHC's concurrency semantics? Cheers, Tim -- Tim Chevalier * chevalier@alum.wellesley.edu * Often in error, never in doubt From stefanor at cox.net Thu Aug 2 22:19:33 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Aug 2 22:11:52 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> Message-ID: <20070803021933.GA5063@localhost.localdomain> On Thu, Aug 02, 2007 at 06:26:36PM -0700, Tim Chevalier wrote: > On 8/2/07, Tim Chevalier wrote: > > I'm forwarding this to ghc-users since nobody answered on > > haskell-cafe, and I'm still curious... (The original message is at > > http://www.nabble.com/Lazy-in-either-argument--t4133855.html) > > > > Replying to myself again, I figured out later that what's really going > on in this example is that when you write: > f = f > (with no type signature) it desugars to: > f = \@a -> let f' = f' in f' > whereas if you write: > f :: Bool > f = f > the code is left more or less as is (if you're compiling with -Onot). > Then the let-body in the unannotated version gets compiled to a loop > that doesn't allocate, whereas (and I don't quite follow why) the > definition in the annotated version gets compiled to a loop that > allocates a new closure on each iteration. Thus, in the example with > two threads, the second version will be pre-empted to run the other > thread that does terminate, whereas the first version will never be > pre-empted. > > This makes sense at least if you consider the desugaring of > polymorphic definitions separately from the semantics of threads... > it's only when they interact that something strange happens. Maybe > it's an extreme corner case, but it still seems weird to me that > adding or removing a type signature should change the semantics of > code like this. It seems to me like the problem is that that the > transformation from (f = f) to (f = let f' = f' in f') isn't valid in > the presence of threads, since in a multithreaded situation the two > are observably different... but is that a bug in the desugarer, or a > bug in GHC's concurrency semantics? If anything I think it's a bug in the code generator/the runtime. We shouldn't be generating uninterruptable loops! Option 1: Don't generate non-allocating loops. In all functions classed as loop-breaker by the occurAnal, generate heap checks even if there are no bytes involved. Pro: Very simple Con: Neil won't be too happy ;) Adds heap checks to pure-arithmetic loops. Option 2: Preempt non-allocating loops. Store somewhere the addresses of a sufficient subset of safe points. Note that the addresses of all info tables is a sufficient subset. On timer interrupt, single step the code until a safepoint is reached. Pro: low overhead and will provide most of the infrastructure I'll need if I ever get around to trying to implement hardware heap checks in GHC. Con: More complicated, especially if single-stepping is so high overhead we wind up needing to implement some other scheme, like linking the bochs core. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070802/dede934c/attachment.bin From simonpj at microsoft.com Fri Aug 3 03:47:24 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Aug 3 03:39:41 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: <20070803021933.GA5063@localhost.localdomain> References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> <20070803021933.GA5063@localhost.localdomain> Message-ID: Stefan is right here. - It's not surprising that with -Onot you get different code from different source programs, even if one can readily be transformed into the other. That's what -O does. | If anything I think it's a bug in the code generator/the runtime. We | shouldn't be generating uninterruptable loops! | | Option 1: Don't generate non-allocating loops. | | Option 2: Preempt non-allocating loops. I would urge caution on (2). It's an absolute swamp, especially when you want to be portable across platforms, into which many have ventured but few have re-emerged. Those that have usually do so by adopting some variation on Option 1. However you can do (1) without allocating: you just need to insert a test into the loop that tests the "please yield" flag, which is set by the interrupt. The key thing is that the thread yields voluntarily and tidily rather than being forcibly pre-empted. Simon From isaacdupree at charter.net Fri Aug 3 07:56:42 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 3 07:57:13 2007 Subject: Annotation for unfolding wanted In-Reply-To: References: <200707301609.26276.georg.martius@web.de> <200707311552.57054.georg.martius@web.de> <200708010942.59069.georg.martius@web.de> Message-ID: <46B317FA.5060402@charter.net> Simon Peyton-Jones wrote: > If it's tail recursive it'll be compiled to a loop. You don't need a pragma. The ~pragma is in order to make an error if it's not a loop. Same way as we don't need type-signatures in export lists and their only purpose is to cause errors when something unexpected and undesirable happens. Isaac From catamorphism at gmail.com Fri Aug 3 17:24:09 2007 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Aug 3 17:16:22 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> <20070803021933.GA5063@localhost.localdomain> Message-ID: <4683d9370708031424w461e29ct6bd2d58052fce988@mail.gmail.com> On 8/3/07, Simon Peyton-Jones wrote: > Stefan is right here. > > - It's not surprising that with -Onot you get different code from different source programs, even if one can readily be transformed into the other. That's what -O does. > Yes, but I found it surprising that just removing a type signature should result in markedly different code. Are there other known situations where that can happen? Cheers, Tim -- Tim Chevalier * chevalier@alum.wellesley.edu * Often in error, never in doubt From isaacdupree at charter.net Fri Aug 3 20:01:18 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 3 20:01:56 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: <4683d9370708031424w461e29ct6bd2d58052fce988@mail.gmail.com> References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> <20070803021933.GA5063@localhost.localdomain> <4683d9370708031424w461e29ct6bd2d58052fce988@mail.gmail.com> Message-ID: <46B3C1CE.7060706@charter.net> Tim Chevalier wrote: > On 8/3/07, Simon Peyton-Jones wrote: >> Stefan is right here. >> >> - It's not surprising that with -Onot you get different code from different source programs, even if one can readily be transformed into the other. That's what -O does. >> > > Yes, but I found it surprising that just removing a type signature > should result in markedly different code. Are there other known > situations where that can happen? It is not _just_ removing a type signature, it is also changing the type from `Bool` to `forall a. a`. An explicit type signature of the latter would have produced the same results as no type signature, I believe. The surprise is that an unconstrained type-variable being variable rather than instantiated to an arbitrary type, makes any difference (since it doesn't, normally, at runtime). I would guess the programs `Bool` and `a` are the same once optimizations are turned on? Maybe GHC could avoid the creation of type-lambdas that are unused (in some sense)... with -Onot... I'm dubious about that. Inserting a preemption test in non-allocating loops seems like a good idea to me (I hate the invisible threat that my program might not thread as threading should work)... any idea how bad the performance impact could be (I guess the test could be specified to branch-predict that the loop wouldn't be interrupted), and whether there could be a pragma to disable that test in certain loops? Is -threaded versus not, relevant here? Isaac From catamorphism at gmail.com Fri Aug 3 20:14:09 2007 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Aug 3 20:06:27 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: <46B3C1CE.7060706@charter.net> References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> <20070803021933.GA5063@localhost.localdomain> <4683d9370708031424w461e29ct6bd2d58052fce988@mail.gmail.com> <46B3C1CE.7060706@charter.net> Message-ID: <4683d9370708031714h2eba3f5eo2aebac043570a950@mail.gmail.com> On 8/3/07, Isaac Dupree wrote: > The surprise is that an unconstrained type-variable being variable > rather than instantiated to an arbitrary type, makes any difference > (since it doesn't, normally, at runtime). Right... it's surprising because types aren't supposed to "matter" at runtime. > I would guess the programs > `Bool` and `a` are the same once optimizations are turned on? Maybe GHC > could avoid the creation of type-lambdas that are unused (in some > sense)... with -Onot... I'm dubious about that. > Right, both programs result in the same runtime behavior if optimizations are turned on. (Which, of course, is another surprising thing: the program with the type signature omitted loops if compiled with -Onot and terminates if compiled with -O.) Cheers, Tim -- Tim Chevalier * chevalier@alum.wellesley.edu * Often in error, never in doubt From stefanor at cox.net Fri Aug 3 20:43:00 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Aug 3 20:35:14 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: <46B3C1CE.7060706@charter.net> References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> <20070803021933.GA5063@localhost.localdomain> <4683d9370708031424w461e29ct6bd2d58052fce988@mail.gmail.com> <46B3C1CE.7060706@charter.net> Message-ID: <20070804004300.GA5238@localhost.localdomain> On Fri, Aug 03, 2007 at 09:01:18PM -0300, Isaac Dupree wrote: > Tim Chevalier wrote: >> On 8/3/07, Simon Peyton-Jones wrote: >>> Stefan is right here. >>> >>> - It's not surprising that with -Onot you get different code from >>> different source programs, even if one can readily be transformed into >>> the other. That's what -O does. >>> >> Yes, but I found it surprising that just removing a type signature >> should result in markedly different code. Are there other known >> situations where that can happen? > > It is not _just_ removing a type signature, it is also changing the type > from `Bool` to `forall a. a`. An explicit type signature of the latter > would have produced the same results as no type signature, I believe. The > surprise is that an unconstrained type-variable being variable rather than > instantiated to an arbitrary type, makes any difference (since it doesn't, > normally, at runtime). I would guess the programs `Bool` and `a` are the > same once optimizations are turned on? Maybe GHC could avoid the creation > of type-lambdas that are unused (in some sense)... with -Onot... I'm > dubious about that. It *does not change the designed semantics at all*. It *tickles a bug*. In the *absence of code generator bugs* it generates *semantically equivalent code*. Do you want inserting or removing type signatures to always tickle the same bugs? Seems like an awfully constraining desgin choice to me. > Inserting a preemption test in non-allocating loops seems like a good idea > to me (I hate the invisible threat that my program might not thread as > threading should work)... any idea how bad the performance impact could be > (I guess the test could be specified to branch-predict that the loop > wouldn't be interrupted), and whether there could be a pragma to disable > that test in certain loops? Is -threaded versus not, relevant here? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070803/2d5b75b4/attachment.bin From bulat.ziganshin at gmail.com Sat Aug 4 00:31:23 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Aug 4 00:27:32 2007 Subject: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?) In-Reply-To: <46B3C1CE.7060706@charter.net> References: <4683d9370708021809i25d963c3j81384a537658ac5e@mail.gmail.com> <4683d9370708021826t38420e90s7d81e5c7cbed2547@mail.gmail.com> <20070803021933.GA5063@localhost.localdomain> <4683d9370708031424w461e29ct6bd2d58052fce988@mail.gmail.com> <46B3C1CE.7060706@charter.net> Message-ID: <1597743820.20070804083123@gmail.com> Hello Isaac, Saturday, August 4, 2007, 4:01:18 AM, you wrote: > Inserting a preemption test in non-allocating loops seems like a good > idea to me (I hate the invisible threat that my program might not thread > as threading should work)... any idea how bad the performance impact > could be with loop unrolling it can be made smaller than any predefined value -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Tue Aug 7 13:14:37 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 7 13:06:37 2007 Subject: Unexpected boxing in generated code In-Reply-To: <404396ef0707091513g19d9bda5u5d246c6a94c1823f@mail.gmail.com> References: <404396ef0707091513g19d9bda5u5d246c6a94c1823f@mail.gmail.com> Message-ID: | I've got an inner loop that I think I can see is strict in the Int | argument being passed around, but that GHC 6.6.1 isn't unboxing. In the | following example both functions take a GHC.Base.Int, which I think | should be an Int#. OK this is an interesting one. Here's the smallest program that demonstrates the problem. foreign import ccall unsafe "stdio.h getchar" getchar :: IO CInt f56 :: State# RealWorld -> Int -> Int f56 s v2 = case (unIO getchar s) of (# s' , v6 #) -> case v2 of I# _ -> f56 s' v2 GHC says this is lazy in v2, which it obviously isn't. Why? Because there's a special hack (introduced after an earlier bug report) in the strictness analyser to account for the fact that a ccall might exit the program. Suppose instead of calling 'getchar' we called 'exit'! Then f56 is not strict in v2 any more. Here was a larger program that demonstrated the problem: do { let len = ; ; when (...) (exitWith ExitSuccess) ; print len } Suppose exitWith doesn't exit; it loops or returns. Then 'len' is sure to be evaluated, and GHC will evaluate it before the 'when'. The hack is in the demand analyser, to make it believe that any I/O operation (including getchar!) might exit instead of returning. OK, so that's the reason you aren't getting proper strictness in your inner loop. What to do about it? It would be easy to revert to the non-hack situation, in which case 'len' might well be evaluated in the program above, even in the program above. To make the program sufficiently lazy you could write do { let len = ; ; when (...) (exitWith ExitSuccess) ; lazy (print len) } Here 'lazy' is a (documented) function that makes its argument appear to be evaluated lazily, so far as the demand analyser is concerned. But this is horribly non-compositional. ANYWHERE you say do { a; b; c } and b might exit, then you should really say 'lazy c'. One could imagine an analysis for "definitely does not exit". But it only really makes sense for IO-ish things. In short, it's hard to see a beautiful solution. Does anyone else have ideas? Simon From ndmitchell at gmail.com Tue Aug 7 13:36:14 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Aug 7 13:28:14 2007 Subject: Unexpected boxing in generated code In-Reply-To: References: <404396ef0707091513g19d9bda5u5d246c6a94c1823f@mail.gmail.com> Message-ID: <404396ef0708071036l5f460950i35e11f7382f3efdd@mail.gmail.com> Hi Simon, > OK this is an interesting one. Here's the smallest program that demonstrates the problem. > > foreign import ccall unsafe "stdio.h getchar" getchar :: IO CInt > > f56 :: State# RealWorld -> Int -> Int > f56 s v2 = case (unIO getchar s) of > (# s' , v6 #) -> > case v2 of I# _ -> f56 s' v2 > > GHC says this is lazy in v2, which it obviously isn't. Why? Because there's a special > hack (introduced after an earlier bug report) in the strictness analyser to account for the > fact that a ccall might exit the program. Suppose instead of calling 'getchar' we called > 'exit'! Then f56 is not strict in v2 any more. > One could imagine an analysis for "definitely does not exit". But it only really > makes sense for IO-ish things. Why not demand that all unsafe foreign imports do not exit the program? If your foreign call does exit the program, then its unlikely to be performance critical. All unsafe FFI functions can then have their strictness analysed as before. Thanks Neil From simonmarhaskell at gmail.com Tue Aug 7 15:52:06 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Aug 7 15:44:09 2007 Subject: Unexpected boxing in generated code In-Reply-To: References: <404396ef0707091513g19d9bda5u5d246c6a94c1823f@mail.gmail.com> Message-ID: <46B8CD66.4060100@gmail.com> Simon Peyton-Jones wrote: > | I've got an inner loop that I think I can see is strict in the Int > | argument being passed around, but that GHC 6.6.1 isn't unboxing. In the > | following example both functions take a GHC.Base.Int, which I think > | should be an Int#. > > OK this is an interesting one. Here's the smallest program that demonstrates the problem. > > foreign import ccall unsafe "stdio.h getchar" getchar :: IO CInt > > f56 :: State# RealWorld -> Int -> Int > f56 s v2 = case (unIO getchar s) of > (# s' , v6 #) -> > case v2 of I# _ -> f56 s' v2 > > GHC says this is lazy in v2, which it obviously isn't. Why? Because there's a special hack (introduced after an earlier bug report) in the strictness analyser to account for the fact that a ccall might exit the program. Suppose instead of calling 'getchar' we called 'exit'! Then f56 is not strict in v2 any more. > > Here was a larger program that demonstrated the problem: > > do { let len = ; > ; when (...) (exitWith ExitSuccess) > ; print len } > > Suppose exitWith doesn't exit; it loops or returns. Then 'len' is sure to be evaluated, and GHC will evaluate it before the 'when'. exitWith in fact doesn't exit: it raises the exit exception, which is caught by the top-level exception handler, which finally arranges to exit. So I imagine the strictness analyser inferred that exitWith returns bottom, and hence it was justified in evaluating len first. This doesn't seem specific to exit, to me. Throwing any exception would trigger this behaviour. Indeed, since we're in the IO monad, I might reasonably expect to have greater control over the evaluation order, and perhaps GHC is right - the strictness analyser should not cause something to be evaluated earlier than normal if that means moving it past a possible effect. In fact this behaviour seems to be essential if we are to be able to use lazy I/O in a sensible way, because otherwise lazy I/O can be evaluated earlier than we expect: do s <- getContents putStr "prompt:"; hFlush stdout case s of ... We are sure to evaluate s, but we better not do it before the putStr (I'm sure the strictness analyser won't do this right now, because it won't infer that putStr returns, but imagine some simpler IO instead). I'm not quite sure what to make of this. On the one hand it's ugly, because we're forced into an evaluation order. But even if it weren't for lazy I/O, I am tempted to think that the IO monad ought to restrict evaluation order, if only so that we can have more control when we want it. So perhaps GHC is doing the right thing. Cheers, Simon From isaacdupree at charter.net Wed Aug 8 19:44:19 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Aug 8 19:46:17 2007 Subject: wondering about -ddump-parsed, rn Message-ID: <46BA5553.803@charter.net> Is ghc -ddump-parsed supposed to give parse-syntactically valid Haskell? It nearly does - the only way I've seen it not do so is infix type-signatures and some infix definitions. Answer: no, look at what it does to the operators with fixities. But, -ddump-rn seems better... file: (@@@) :: a a @@@ b = a + b : a + b ==================== Parser ==================== @@@ :: a @@@ a b = ((a + b) : a) + b ==================== Renamer ==================== @@@ :: a @@@ a b = (a + b) : (a + b) It would be interesting if that was a source-to-source transformation on Haskell: a way to delete all the comments and formatting of the original file. Putting parentheses around infix used as prefix would be nice. Of course... the renamer output depends on other modules, and must for the precise reason of imported fixity declarations! GHC isn't trying to do this so I really have no reason to ask it to :) P.S. this (-ddump-) is a nice way to see how some stages of GHC's processing are done, to get to know them a little, I think, after also looking through some code and Commentary Isaac From simonpj at microsoft.com Thu Aug 9 05:13:27 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 9 05:05:23 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <46BA5553.803@charter.net> References: <46BA5553.803@charter.net> Message-ID: -ddump-parsed shows the program after parsing. All operator application are parsed *left-associative* with one precedence. Then the renamer re-associates them to respect precedence and associativity. So, no, -ddump-parsed will definitely not give syntactically valid Haskell. -ddump-rn probably will though. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Isaac Dupree | Sent: 09 August 2007 00:44 | To: GHC Users | Subject: wondering about -ddump-parsed, rn | | Is ghc -ddump-parsed supposed to give parse-syntactically valid Haskell? | It nearly does - the only way I've seen it not do so is infix | type-signatures and some infix definitions. Answer: no, look at what it | does to the operators with fixities. But, -ddump-rn seems better... | | file: | | (@@@) :: a | a @@@ b = a + b : a + b | | ==================== Parser ==================== | @@@ :: a | @@@ a b = ((a + b) : a) + b | | ==================== Renamer ==================== | @@@ :: a | @@@ a b = (a + b) : (a + b) | | | It would be interesting if that was a source-to-source transformation on | Haskell: a way to delete all the comments and formatting of the original | file. Putting parentheses around infix used as prefix would be nice. | Of course... the renamer output depends on other modules, and must for | the precise reason of imported fixity declarations! GHC isn't trying to | do this so I really have no reason to ask it to :) | | P.S. this (-ddump-) is a nice way to see how some stages of GHC's | processing are done, to get to know them a little, I think, after also | looking through some code and Commentary | | Isaac | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From isaacdupree at charter.net Thu Aug 9 05:51:12 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Aug 9 05:53:22 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: References: <46BA5553.803@charter.net> Message-ID: <46BAE390.5020001@charter.net> Simon Peyton-Jones wrote: > -ddump-parsed shows the program after parsing. All operator application are parsed *left-associative* with one precedence. Then the renamer re-associates them to respect precedence and associativity. > > So, no, -ddump-parsed will definitely not give syntactically valid Haskell. -ddump-rn probably will though. yes, in that case, would anyone mind if I find an easy way to change GHC to parenthesize those non-infix uses of operators? :) hmm... maybe _I_ would mind, since it makes "what GHC is doing" just a tiny bit less transparent to the user of -ddump-{rn,parsed}. :-) Isaac From Christian.Maeder at dfki.de Thu Aug 9 08:56:54 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Aug 9 08:48:54 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <46BA5553.803@charter.net> References: <46BA5553.803@charter.net> Message-ID: <46BB0F16.9010406@dfki.de> Isaac Dupree wrote: > Is ghc -ddump-parsed supposed to give parse-syntactically valid Haskell? > It nearly does - the only way I've seen it not do so is infix > type-signatures and some infix definitions. Answer: no, look at what it > does to the operators with fixities. But, -ddump-rn seems better... > > file: > > (@@@) :: a > a @@@ b = a + b : a + b > > ==================== Parser ==================== > @@@ :: a > @@@ a b = ((a + b) : a) + b Could -ddump-parsed not simply omit these (wrong) left-associative parentheses? What information would be lost? Cheers Christian From isaacdupree at charter.net Thu Aug 9 10:19:43 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Aug 9 10:21:56 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <46BB0F16.9010406@dfki.de> References: <46BA5553.803@charter.net> <46BB0F16.9010406@dfki.de> Message-ID: <46BB227F.8060301@charter.net> Christian Maeder wrote: > Isaac Dupree wrote: >> @@@ a b = ((a + b) : a) + b > > Could -ddump-parsed not simply omit these (wrong) left-associative > parentheses? What information would be lost? The information about how GHC's parser currently handles infixes. The intent of the -ddump-xxx flags (I think) is to give a readable representation of ghc's internal state, e.g. for debugging. However it very well might be that omitting those parentheses would yield a Haskell module equivalent to the original file, which would be a nice thing to be able to get somehow, anyway. Isaac From igloo at earth.li Thu Aug 9 11:01:01 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 9 10:52:55 2007 Subject: GHC 6.8 release plans Message-ID: <20070809150101.GA4531@matrix.chaos.earth.li> Hi all, This is just to let you know our plans for the first release of the up-coming 6.8 branch (which will be called 6.8.1). We are aiming to have a release candidate by the end of August, with all the high priority bugs milestoned for 6.8 fixed: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&priority=high&milestone=6.8&order=priority If there are any other bugs that you think are critical for 6.8.1, then please make your case and add yourself to the bug's CC list now! We intend to drop support for Win9x, as we are unable to test it. I understand that the OS itself is no longer supported, and the small number of Win9x users remaining can continue to use the older GHC releases. However, if anyone feels strongly that Win9x support should be continued, and is willing to lead the effort to maintain and test it, then we will of course be willing to help out with any problems that arise. We expect that the release of 6.8.1 will follow, around the end of September. Thanks Ian From stefanor at cox.net Thu Aug 9 13:56:25 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Aug 9 13:48:22 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <46BAE390.5020001@charter.net> References: <46BA5553.803@charter.net> <46BAE390.5020001@charter.net> Message-ID: <20070809175625.GA3361@localhost.localdomain> On Thu, Aug 09, 2007 at 06:51:12AM -0300, Isaac Dupree wrote: > Simon Peyton-Jones wrote: >> -ddump-parsed shows the program after parsing. All operator application >> are parsed *left-associative* with one precedence. Then the renamer >> re-associates them to respect precedence and associativity. >> So, no, -ddump-parsed will definitely not give syntactically valid >> Haskell. -ddump-rn probably will though. > > yes, in that case, would anyone mind if I find an easy way to change GHC to > parenthesize those non-infix uses of operators? :) hmm... maybe _I_ would > mind, since it makes "what GHC is doing" just a tiny bit less transparent > to the user of -ddump-{rn,parsed}. :-) I fixed an identical bug in a copy of the code a few months ago. http://haskell.org/pipermail/libraries/2007-April/007317.html Unfortunately, I think TH was forked off from the in-compiler syntax tree too long ago for my fix to be useful... Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070809/f8b4554a/attachment.bin From isaacdupree at charter.net Fri Aug 10 07:25:19 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 10 07:27:45 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <20070809175625.GA3361@localhost.localdomain> References: <46BA5553.803@charter.net> <46BAE390.5020001@charter.net> <20070809175625.GA3361@localhost.localdomain> Message-ID: <46BC4B1F.3040703@charter.net> Stefan O'Rear wrote: > On Thu, Aug 09, 2007 at 06:51:12AM -0300, Isaac Dupree wrote: >> Simon Peyton-Jones wrote: >>> -ddump-parsed shows the program after parsing. All operator application >>> are parsed *left-associative* with one precedence. Then the renamer >>> re-associates them to respect precedence and associativity. >>> So, no, -ddump-parsed will definitely not give syntactically valid >>> Haskell. -ddump-rn probably will though. >> yes, in that case, would anyone mind if I find an easy way to change GHC to >> parenthesize those non-infix uses of operators? :) hmm... maybe _I_ would >> mind, since it makes "what GHC is doing" just a tiny bit less transparent >> to the user of -ddump-{rn,parsed}. :-) > > I fixed an identical bug in a copy of the code a few months ago. > > http://haskell.org/pipermail/libraries/2007-April/007317.html > > Unfortunately, I think TH was forked off from the in-compiler syntax > tree too long ago for my fix to be useful... Also these -ddump- outputs qualified infix usages {{{ `P.++` }}} as an infix, where the backticks should not be there if it was Haskell. If you know what you did to fix TH, can you easily add all those fixes to this copy of the code? (muses hopefully) I see Simon PJ has removed the "wrong" -ddump-parsed parentheses :) Isaac From simonpj at microsoft.com Fri Aug 10 07:50:41 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Aug 10 07:42:34 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <46BC4B1F.3040703@charter.net> References: <46BA5553.803@charter.net> <46BAE390.5020001@charter.net> <20070809175625.GA3361@localhost.localdomain> <46BC4B1F.3040703@charter.net> Message-ID: | I see Simon PJ has removed the "wrong" -ddump-parsed parentheses :) Ah yes, should have mentioned that. I think it's better now; turned out to be quick and easy. -dppr-debug shows the old form, for GHC debugging. Simon From peter.ilberg at gmail.com Fri Aug 10 10:14:27 2007 From: peter.ilberg at gmail.com (Peter Ilberg) Date: Fri Aug 10 10:12:00 2007 Subject: Display problem with ghci (:e) and vim Message-ID: Hello! I've noticed an odd display problem with ghci and vim. The problem occurs with ghci-6.6 and vim-6 on Mac OS X 10.4.9 (Terminal.app and uxrvt in X11.app) and with ghci-6.2.2, ghci-6.6.1 and vim-7.0 on OpenBSD 4.1 (via PuTTY from Windows). 1 - Resize your terminal window to 40 lines. 2 - Start ghci. 3 - :set editor vim 4 - :edit File.hs (pick an existing file) Vim doesn't display the file contents properly in the bottom half of my terminal window (it doesn't display parts of the file). But it does correctly display the : command line at the bottom of the screen. Refreshing the display with Ctrl-L does not help. Infact, it makes things worse in some cases. Resizing the window with the mouse, or by typing resize, or by export LINES=40 does not help either. I don't see this problem under any of these configurations if I use hugs instead of ghci. Has anyone noticed this as well? Is there a workaround? (other than using hugs) Thanks, -- Peter From igloo at earth.li Fri Aug 10 12:14:51 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 10 12:06:42 2007 Subject: Display problem with ghci (:e) and vim In-Reply-To: References: Message-ID: <20070810161451.GA5962@matrix.chaos.earth.li> On Fri, Aug 10, 2007 at 09:14:27AM -0500, Peter Ilberg wrote: > > I've noticed an odd display problem with ghci and vim. The problem occurs > with ghci-6.6 and vim-6 on Mac OS X 10.4.9 (Terminal.app and uxrvt in > X11.app) and with ghci-6.2.2, ghci-6.6.1 and vim-7.0 on OpenBSD 4.1 (via > PuTTY from Windows). I can't reproduce this in a uxterm, rxvt or putty, with ghci 6.6 and vim 7.0. Thanks Ian From isaacdupree at charter.net Fri Aug 10 12:32:48 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 10 12:35:14 2007 Subject: compiler-detected nontermination Message-ID: <46BC9330.6030904@charter.net> Firstly I'm assuming that GHC's strictness analyser notices things like (bottom = bottom) or could easily do so - please correct me if I'm wrong. GHC in its RTS already throws Nontermination exception in some cases. I think it would be nice if, when the compiler detected nontermination, to replace it with an exception and emit a warning message (hmm... if GHC Core loses source code information, a warning message might be difficult). Is there any intentional use of certain nontermination? This is inspired by the problem that supplying default definitions for class methods that refer to each other (such as Eq's (==) and (/=)), doesn't warn you if you don't define them and only yields your program not to terminate, when you run it! (noticed on haskell-prime list.) Even if it can't be detected automatically, maybe a pragma for classes to tell the compiler what documentation often tells users: {-# MINIMAL_INSTANCE Eq (==) OR (/=) #-} or for Data.Bits.Bits "Minimal complete definition: .&., .|., xor, complement, (shift or (shiftL and shiftR)), (rotate or (rotateL and rotateR)), bitSize and isSigned. " {-# MINIMAL_INSTANCE Bits (.&.) AND (.|.) AND xor AND complement AND (shift OR (shiftL AND shiftR)) AND (rotate OR (rotateL AND rotateR)) AND bitSize AND isSigned #-} Except that Bits is a stupid class in which you're *supposed to* leave bitSize undefined for unlimited-precision types like Integer... GHC already warns if you don't define bitSize... Maybe "AND" --> "," , "OR" --> "|" or something Thoughts? Isaac From droundy at darcs.net Fri Aug 10 12:49:02 2007 From: droundy at darcs.net (David Roundy) Date: Fri Aug 10 12:40:58 2007 Subject: compiler-detected nontermination In-Reply-To: <46BC9330.6030904@charter.net> References: <46BC9330.6030904@charter.net> Message-ID: <20070810164902.GF30654@darcs.net> On Fri, Aug 10, 2007 at 01:32:48PM -0300, Isaac Dupree wrote: > GHC in its RTS already throws Nontermination exception in some cases. I > think it would be nice if, when the compiler detected nontermination, to > replace it with an exception and emit a warning message (hmm... if GHC > Core loses source code information, a warning message might be > difficult). Is there any intentional use of certain nontermination? One possible use for nontermination would be as a workaround for something like Catch (which defines its own workarounds, but if it didnt...). Catch complains if your code calls error, so you could define your own: myerror :: String -> a myerror s = myerror s The type of this function guarantees that it is either non-terminating or generates an exception, so if powerful static checking prevented a programmer from writing an exception-generating code, the desperate programmer always has the fallback of generating non-terminating code (a good reason for allowing error in the language, I suppose). -- David Roundy Department of Physics Oregon State University From marco-oweber at gmx.de Fri Aug 10 16:06:24 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Aug 10 15:58:18 2007 Subject: Display problem with ghci (:e) and vim In-Reply-To: References: Message-ID: <20070810200624.GA22871@gmx.de> > Hello! > > I've noticed an odd display problem with ghci and vim. The problem occurs > with ghci-6.6 and vim-6 on Mac OS X 10.4.9 (Terminal.app and uxrvt in > X11.app) and with ghci-6.2.2, ghci-6.6.1 and vim-7.0 on OpenBSD 4.1 (via > PuTTY from Windows). > > 1 - Resize your terminal window to 40 lines. > 2 - Start ghci. > 3 - :set editor vim > 4 - :edit File.hs (pick an existing file) > > Vim doesn't display the file contents properly in the bottom half of my > terminal window (it doesn't display parts of the file). But it does > correctly display the : command line at the bottom of the screen. Do you see a lot of control structures scattering around? The way you get them when using !vim within vim? (you can still use :q! do quit) your TERMINAL env var might be important. Does it look different when additionally running all within screen? Perhaps :h terminal* can also help? I'm no experienced user with this stuff. It did just work for me all the time :) Marc From isaacdupree at charter.net Sat Aug 11 12:16:51 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Aug 11 12:19:34 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <46BA5553.803@charter.net> References: <46BA5553.803@charter.net> Message-ID: <46BDE0F3.4040005@charter.net> Also SPECIALIZE is turned into SPECIALIZE NOINLINE -- which has an effect on error messages too (which might be considered a bug). And instances look very weird.... source: instance Class.Eq Integer where CInteger a == CInteger b = a == b ghc-6.6.1 -ddump-parsed: instance {Class.Eq Integer} where [] { == CInteger a CInteger b = a == b } most recent HEAD -ddump-parsed: instance Class.Eq Integer where [] [] { == CInteger a CInteger b = a == b } Except for the two extra "[]" and the three necessary missing pairs of parentheses (or else using "==" in an infix position), this looks like valid Haskell And then my Num instance becomes (in HEAD) instance Class.Num Integer where [] [] { + CInteger a CInteger b = mkInteger (addInteger a b) * CInteger a CInteger b = mkInteger (multiplyInteger a b) negate (CInteger a) = mkInteger (negateInteger a) abs (CInteger a) = mkInteger (absInteger a) signum (CInteger a) = mkInteger (signumInteger a) fromInteger unboundedIntegral = mkInteger (uncheckedFromIntegral unboundedIntegral) } , which uses curly braces but not semicolons, so the layout wouldn't work in Haskell, for multiple functions defined in the instance, too. Isaac From mads_lindstroem at yahoo.dk Sun Aug 12 04:05:17 2007 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Sun Aug 12 04:00:44 2007 Subject: (Compile ghc 6.7) Cannot find package base Message-ID: <1186905917.4068.36.camel@localhost.localdomain> Hi all I tried compiling ghc 6.7 during the night. I used the following script: #!/bin/bash rm -rf $HOME/ghc darcs get --partial http://darcs.haskell.org/ghc cd ghc chmod +x darcs-all ./darcs-all get ./darcs-all --extra get sh boot ./configure --prefix=$HOME echo "Checkpoint make" make echo "Checkpoint make install" make install but when I run ghci I get: GHCi, version 6.7.20070810: http://www.haskell.org/ghc/ :? for help :1:22: Failed to load interface for `System.IO': Use -v to see a list of the files searched for. :1:22: Failed to load interface for `System.IO': Use -v to see a list of the files searched for. :1:22: Failed to load interface for `System.IO': Use -v to see a list of the files searched for. ghc-6.7.20070810: panic! (the 'impossible' happened) (GHC version 6.7.20070810 for i386-unknown-linux): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Is this really a bug or am I doing something wrong? I also tried: ghc-pkg check and got: package ghc-6.7.20070810 has missing dependencies: hpc, template-haskell, readline, unix, Cabal, base, haskell98 If anybody is interested I got the complete build logs, but given there size 2.2 megabytes (180 kilo when compressed with gzip) I choose not to include them in the message. Greetings, Mads Lindstr?m From stefanor at cox.net Sun Aug 12 04:23:34 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Aug 12 04:15:24 2007 Subject: (Compile ghc 6.7) Cannot find package base In-Reply-To: <1186905917.4068.36.camel@localhost.localdomain> References: <1186905917.4068.36.camel@localhost.localdomain> Message-ID: <20070812082334.GA11963@localhost.localdomain> On Sun, Aug 12, 2007 at 10:05:17AM +0200, Mads Lindstr?m wrote: > Hi all > > I tried compiling ghc 6.7 during the night. I used the following script: > ... > Failed to load interface for `System.IO': > Use -v to see a list of the files searched for. > ghc-6.7.20070810: panic! (the 'impossible' happened) > (GHC version 6.7.20070810 for i386-unknown-linux): > interactiveUI:setBuffering > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Is this really a bug or am I doing something wrong? This is almost certainly a bug, and you are at least the fourth person affected. Magnus Therning claimed on the #ghc IRC channel earlier to have a complete fix, which will be published in a few hours after he's awake again. (As a check, you may want to try *compiling* a trivial module. The symptom seen by the previous three people was "Failed to load interface for `Prelude', and the 'ghc-pkg list' reveals only ghc and rts.) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070812/672c6b7e/attachment.bin From eivuokko at gmail.com Sun Aug 12 18:22:06 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Sun Aug 12 18:13:49 2007 Subject: Visual Haskell will not Install with Visual Studio 2005, Express Edition In-Reply-To: References: Message-ID: Hi, On 7/27/07, Sean Johnson wrote: > Is there some way to install Visual Haskell with VS2005, Express? Perhaps > some workaround or hack? It's probably impossible. Feature matrix for Visual Studio products says "Use 3rd party controls and content. No Macros, Add-ins or Packages". [1] Best regards, Esa [1] http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx From seth at cql.com Sun Aug 12 18:30:50 2007 From: seth at cql.com (Seth Kurtzberg) Date: Sun Aug 12 18:23:07 2007 Subject: Visual Haskell will not Install with Visual Studio 2005, Express Edition In-Reply-To: References: Message-ID: <07f401c7dd30$6f928330$4eb78990$@com> It won't install with the full edition either. -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Esa Ilari Vuokko Sent: Sunday, August 12, 2007 6:22 PM To: Sean Johnson Cc: glasgow-haskell-bugs@haskell.org; glasgow-haskell-users@haskell.org Subject: Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition Hi, On 7/27/07, Sean Johnson wrote: > Is there some way to install Visual Haskell with VS2005, Express? Perhaps > some workaround or hack? It's probably impossible. Feature matrix for Visual Studio products says "Use 3rd party controls and content. No Macros, Add-ins or Packages". [1] Best regards, Esa [1] http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx _______________________________________________ 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 Sun Aug 12 18:34:09 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Aug 12 18:24:40 2007 Subject: Visual Haskell will not Install with Visual Studio 2005, Express Edition In-Reply-To: References: Message-ID: <1186958049.28208.43.camel@localhost> On Thu, 2007-07-26 at 23:51 -0700, Sean Johnson wrote: > Hi Everyone, > > Is there some way to install Visual Haskell with VS2005, Express? > Perhaps some workaround or hack? I believe that free version of VS is specifically designed not to allow any plugins, you have to pay for the the full version for that sadly. As a free alternative, emacs and eclipse have Haskell modes and many other editors have Haskell syntax highlighting. Duncan From igloo at earth.li Sun Aug 12 19:32:37 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Aug 12 19:24:25 2007 Subject: (Compile ghc 6.7) Cannot find package base In-Reply-To: <1186905917.4068.36.camel@localhost.localdomain> References: <1186905917.4068.36.camel@localhost.localdomain> Message-ID: <20070812233237.GA17969@matrix.chaos.earth.li> On Sun, Aug 12, 2007 at 10:05:17AM +0200, Mads Lindstr?m wrote: > > Is this really a bug or am I doing something wrong? Thanks for the report; it was a bug. Now fixed in the HEAD. By the way, problems with the HEAD are best reported on the cvs-ghc@haskell.org list. Thanks Ian From seth at cql.com Sun Aug 12 19:34:25 2007 From: seth at cql.com (Seth Kurtzberg) Date: Sun Aug 12 19:26:41 2007 Subject: Visual Haskell will not Install with Visual Studio 2005, Express Edition In-Reply-To: <1186958049.28208.43.camel@localhost> References: <1186958049.28208.43.camel@localhost> Message-ID: <07f701c7dd39$51664640$f432d2c0$@com> I was not aware of the Eclipse support, so thanks for that information. However, Visual Haskell will not install on the full version of Visual Studio 2005 either. To make sure this was not an issue specific to my installation, I completely wiped a disk, installed Windows, installed Visual Studio 2005, and then attempted to install Visual Haskell. A fatal error occurs near the end of the install. I don't have the error text in front of me, but I'll send an email tomorrow when I'll have access to it. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Duncan Coutts Sent: Sunday, August 12, 2007 6:34 PM To: Sean Johnson Cc: glasgow-haskell-bugs@haskell.org; glasgow-haskell-users@haskell.org Subject: Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition On Thu, 2007-07-26 at 23:51 -0700, Sean Johnson wrote: > Hi Everyone, > > Is there some way to install Visual Haskell with VS2005, Express? > Perhaps some workaround or hack? I believe that free version of VS is specifically designed not to allow any plugins, you have to pay for the the full version for that sadly. As a free alternative, emacs and eclipse have Haskell modes and many other editors have Haskell syntax highlighting. Duncan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From loppermann at acm.org Wed Aug 15 12:24:50 2007 From: loppermann at acm.org (Lars Oppermann) Date: Wed Aug 15 12:16:24 2007 Subject: setting the default package path Message-ID: Hi all, I'm quite new to Haskell and GHC, please accept my apologies if I have missed something obvious in the FAQ/Documentation... On Windows, using the binary distribution of GHC Cabal packages are, by default, placed into C:\Program FIles\Haskell - if the --prefix option is not used when configuring the package in order to indicate some other location. Can I change this default location? Thanks, Lars -- Lars Oppermann Hamburg, Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070815/5cb4d708/attachment.htm From brianh at metamilk.com Wed Aug 15 13:41:53 2007 From: brianh at metamilk.com (Brian Hulley) Date: Wed Aug 15 13:33:02 2007 Subject: Status of GHC runtime dependency on GNU multi precision arithmetic library Message-ID: <46C33AE1.9080601@metamilk.com> Hi, I know this is a sensitive issue and I absolutely don't want to start any kind of discussion about the merits or otherwise of LGPL, but I was wondering if there are any plans to remove the GNU mp library from the runtime so that it would be possible to distribute native executables compiled with GHC without having to deal with the additional issues raised by the current inclusion of this LGPL component in the runtime. (Afaik everything else in ghc is under a BSD3 license.) It's less of an issue on Linux where libgmp is dynamically linked but when thinking about using Haskell ghc for creating Windows apps it is for me a real problem, because it would mean I'd have to distribute the code for my app as a library along with the code as an executable, thus doubling the download size for my apps as well as having to include a license that has to explain to a possibly non-technical user that although the program includes code that is libre/gratis free the program is not itself free etc etc... Regards, Brian. From stefanor at cox.net Wed Aug 15 14:33:09 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Aug 15 14:24:43 2007 Subject: Status of GHC runtime dependency on GNU multi precision arithmetic library In-Reply-To: <46C33AE1.9080601@metamilk.com> References: <46C33AE1.9080601@metamilk.com> Message-ID: <20070815183309.GD3020@localhost.localdomain> On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote: > Hi, > I know this is a sensitive issue and I absolutely don't want to start any > kind of discussion about the merits or otherwise of LGPL, but I was > wondering if there are any plans to remove the GNU mp library from the > runtime so that it would be possible to distribute native executables > compiled with GHC without having to deal with the additional issues raised > by the current inclusion of this LGPL component in the runtime. (Afaik > everything else in ghc is under a BSD3 license.) There is an interest in removing GMP, motivated partly by licensing but also due to portabiltity concerns and the fact that the use of GHC's memory manager in GMP prevents FFI code from using GMP safely. http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes > It's less of an issue on Linux where libgmp is dynamically linked but when > thinking about using Haskell ghc for creating Windows apps it is for me a > real problem, because it would mean I'd have to distribute the code for my > app as a library along with the code as an executable, thus doubling the > download size for my apps as well as having to include a license that has > to explain to a possibly non-technical user that although the program > includes code that is libre/gratis free the program is not itself free etc > etc... Huh? AFAIK the LGPL is only an issue for the commercial/proprietary users of Haskell; gratis/libre works would continue to be gratis/libre after linking with GMP. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070815/b1c19c00/attachment.bin From igloo at earth.li Wed Aug 15 14:53:12 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 15 14:44:47 2007 Subject: Status of GHC runtime dependency on GNU multi precision arithmetic library In-Reply-To: <46C33AE1.9080601@metamilk.com> References: <46C33AE1.9080601@metamilk.com> Message-ID: <20070815185312.GA3228@matrix.chaos.earth.li> On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote: > > I know this is a sensitive issue and I absolutely don't want to start > any kind of discussion about the merits or otherwise of LGPL, but I was > wondering if there are any plans to remove the GNU mp library from the > runtime I'll be looking at making it optional once 6.8.1 is out of the way, but you will need to use a GHC compiled with an alternative; you won't be able to make a non-GMP program with a GMP GHC. > (Afaik everything else in ghc is under a BSD3 license.) Readline isn't, but is already optional, and won't get linked into programs you write unless you actually use it. Thanks Ian From igloo at earth.li Wed Aug 15 14:59:34 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 15 14:51:09 2007 Subject: setting the default package path In-Reply-To: References: Message-ID: <20070815185934.GB3228@matrix.chaos.earth.li> On Wed, Aug 15, 2007 at 06:24:50PM +0200, Lars Oppermann wrote: > > On Windows, using the binary distribution of GHC Cabal packages are, by > default, placed into C:\Program FIles\Haskell - if the --prefix option is > not used when configuring the package in order to indicate some other > location. > > Can I change this default location? No (apart from changing the system-wide "Program Files" location). Thanks Ian From Alistair_Bayley at invescoperpetual.co.uk Thu Aug 16 04:06:06 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Thu Aug 16 03:57:39 2007 Subject: Status of GHC runtime dependency on GNU multi precisionarithmetic library In-Reply-To: <20070815183309.GD3020@localhost.localdomain> References: <46C33AE1.9080601@metamilk.com> <20070815183309.GD3020@localhost.localdomain> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA901BDFC26@GBLONXMB02.corp.amvescap.net> > From: glasgow-haskell-users-bounces@haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Stefan O'Rear > > http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes > > > It's less of an issue on Linux where libgmp is dynamically > linked but when > > thinking about using Haskell ghc for creating Windows apps > it is for me a > > real problem, because it would mean I'd have to distribute > the code for my > > app as a library along with the code as an executable, thus > doubling the > > download size for my apps as well as having to include a > license that has > > to explain to a possibly non-technical user that although > the program > > includes code that is libre/gratis free the program is not > itself free etc > > etc... > > Huh? AFAIK the LGPL is only an issue for the commercial/proprietary > users of Haskell; gratis/libre works would continue to be gratis/libre > after linking with GMP. I could be wrong, but I believe that Brian's intention is indeed to release a commercial/proprietary app, hence it is possibly an issue for him. I'm not sure about having to distribute the code for his app; I thought the point of the LGPL license was to allow proprietary (non-GPL?) apps to link to LGPL libs. Wouldn't he just have to distribute the code for GMP? But then, I understand less about FSF licensing than pretty much everyone else on this list, so I'll shut up now... Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From loppermann at acm.org Thu Aug 16 05:30:36 2007 From: loppermann at acm.org (Lars Oppermann) Date: Thu Aug 16 05:22:10 2007 Subject: Status of GHC runtime dependency on GNU multi precisionarithmetic library In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA901BDFC26@GBLONXMB02.corp.amvescap.net> References: <46C33AE1.9080601@metamilk.com> <20070815183309.GD3020@localhost.localdomain> <125EACD0CAE4D24ABDB4D148C4593DA901BDFC26@GBLONXMB02.corp.amvescap.net> Message-ID: On 8/16/07, Bayley, Alistair wrote: > I could be wrong, but I believe that Brian's intention is indeed to > release a commercial/proprietary app, hence it is possibly an issue for > him. I'm not sure about having to distribute the code for his app; I > thought the point of the LGPL license was to allow proprietary > (non-GPL?) apps to link to LGPL libs. Wouldn't he just have to > distribute the code for GMP? But then, I understand less about FSF > licensing than pretty much everyone else on this list, so I'll shut up > now... As long as GMP isn't modified, it is not even necessary to distribute the source code. It is only necessary to include the license information as part of the "combined work". (Sect. 4 of LGPL). Furthermore you need to make sure, that a user can replace the LGPL component with another version. Dynamic linking is the easiest way to do this. However, conveying object code that can be relinked statically seems to be OK too. I cannot say that I get the definition of "minimal corresponding code" in the LGPL completely. The essence however seems to be that users must be able to replace the LGPL component with another version. I also understand that it is not necessary to include it directly in your binary distribution, as long as you provide a mechanism through which the necessary material can be obtained (e.g. separate download). The idea is that if there is a bug in GMP but the author of the combined work isn't willing or able to provide an updated version of his app that is built with the fixed version, users must be able to create their own version that uses the fixed GMP version. Cheers, /Lars From peter at syncad.com Thu Aug 16 06:05:15 2007 From: peter at syncad.com (Peter Hercek) Date: Thu Aug 16 06:02:22 2007 Subject: hyperlinked haskell 98 grammar Message-ID: Hi, I was improving my Haskell knowledge lately and I created a small dhtml application which allows browsing of Haskell 98 grammar. I contains both forward and backward hyperlinks. By backward hyperlink I mean that you can click on an a production head and you get a popup list box where you can navigate to any production using the nonterminal. If you like it please save and use your local copy since the server cannot handle much load. http://www.hck.sk/users/peter/ Peter. From duncan.coutts at worc.ox.ac.uk Thu Aug 16 07:43:12 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 16 07:33:29 2007 Subject: Status of GHC runtime dependency on GNU multi precision arithmetic library In-Reply-To: <46C33AE1.9080601@metamilk.com> References: <46C33AE1.9080601@metamilk.com> Message-ID: <1187264592.24215.160.camel@localhost> On Wed, 2007-08-15 at 18:41 +0100, Brian Hulley wrote: > Hi, > I know this is a sensitive issue and I absolutely don't want to start > any kind of discussion about the merits or otherwise of LGPL, but I was > wondering if there are any plans to remove the GNU mp library from the > runtime so that it would be possible to distribute native executables > compiled with GHC without having to deal with the additional issues > raised by the current inclusion of this LGPL component in the runtime. > (Afaik everything else in ghc is under a BSD3 license.) > > It's less of an issue on Linux where libgmp is dynamically linked but > when thinking about using Haskell ghc for creating Windows apps it is > for me a real problem, Sounds to me like the simlest solution for you would be if GHC could use a dynamically linked gmp.dll on Windows. That also sounds like much less work that replacing gmp completely. Has anyone tried this? Duncan From ndmitchell at gmail.com Thu Aug 16 09:09:47 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Aug 16 09:01:19 2007 Subject: hyperlinked haskell 98 grammar In-Reply-To: References: Message-ID: <404396ef0708160609v18b5b6d7s58c6ea43417d34c6@mail.gmail.com> Hi Peter, A nice application. One suggestion: I would have implemented it so that a maximum on one backward hyperlink menu could be visible at once - try clicking on two RHS's and you'll get too "menus" visible at the same time. You also might want to mail this out on haskell-cafe - which is more appropriate for "general haskell" things, ghc-users is more for direct issues with GHC (although haskell-cafe can also be used for those) Thanks Neil On 8/16/07, Peter Hercek wrote: > Hi, > > I was improving my Haskell knowledge lately and I created a small dhtml application which allows browsing of > Haskell 98 grammar. I contains both forward and backward hyperlinks. By backward hyperlink I mean that you can > click on an a production head and you get a popup list box where you can navigate to any production using the > nonterminal. If you like it please save and use your local copy since the server cannot handle much load. > > http://www.hck.sk/users/peter/ > > Peter. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From ndmitchell at gmail.com Thu Aug 16 09:12:50 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Aug 16 09:04:21 2007 Subject: hyperlinked haskell 98 grammar In-Reply-To: <404396ef0708160609v18b5b6d7s58c6ea43417d34c6@mail.gmail.com> References: <404396ef0708160609v18b5b6d7s58c6ea43417d34c6@mail.gmail.com> Message-ID: <404396ef0708160612p518faf5di15335d89a6d124f4@mail.gmail.com> Hi In addition, perhaps this should be relocated to haskell.org, if your server is not suitable for a large volume of users. I think it should also be integrated somewhere (perhaps a link from the HTML report, and certainly on the wiki) Thanks Neil On 8/16/07, Neil Mitchell wrote: > Hi Peter, > > A nice application. One suggestion: I would have implemented it so > that a maximum on one backward hyperlink menu could be visible at once > - try clicking on two RHS's and you'll get too "menus" visible at the > same time. > > You also might want to mail this out on haskell-cafe - which is more > appropriate for "general haskell" things, ghc-users is more for direct > issues with GHC (although haskell-cafe can also be used for those) > > Thanks > > Neil > > On 8/16/07, Peter Hercek wrote: > > Hi, > > > > I was improving my Haskell knowledge lately and I created a small dhtml application which allows browsing of > > Haskell 98 grammar. I contains both forward and backward hyperlinks. By backward hyperlink I mean that you can > > click on an a production head and you get a popup list box where you can navigate to any production using the > > nonterminal. If you like it please save and use your local copy since the server cannot handle much load. > > > > http://www.hck.sk/users/peter/ > > > > Peter. > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > From eivuokko at gmail.com Thu Aug 16 09:16:54 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Thu Aug 16 09:08:29 2007 Subject: hyperlinked haskell 98 grammar In-Reply-To: <404396ef0708160612p518faf5di15335d89a6d124f4@mail.gmail.com> References: <404396ef0708160609v18b5b6d7s58c6ea43417d34c6@mail.gmail.com> <404396ef0708160612p518faf5di15335d89a6d124f4@mail.gmail.com> Message-ID: On 8/16/07, Neil Mitchell wrote: > In addition, perhaps this should be relocated to haskell.org, if your > server is not suitable for a large volume of users. I think it should > also be integrated somewhere (perhaps a link from the HTML report, and > certainly on the wiki) Agreed, the page seems like an useful resource. :-) Best regards, Esa From brianh at metamilk.com Thu Aug 16 09:22:04 2007 From: brianh at metamilk.com (Brian Hulley) Date: Thu Aug 16 09:13:12 2007 Subject: Status of GHC runtime dependency on GNU multi precision arithmetic library In-Reply-To: <20070815183309.GD3020@localhost.localdomain> References: <46C33AE1.9080601@metamilk.com> <20070815183309.GD3020@localhost.localdomain> Message-ID: <46C44F7C.5020003@metamilk.com> Stefan O'Rear wrote: > On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote: > >> ... I was >> wondering if there are any plans to remove the GNU mp library from the >> runtime > ... http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes > Thanks for the link. >> ... although the program >> includes code that is libre/gratis free the program is not itself free etc >> etc... >> > > Huh? ... I meant if you are distributing a proprietary program then you have the problem of trying to explain to an end-user all the intricacies involved with the LGPL without conveying the impression that the whole program is free. My impression is that someone who doesn't know anything about programming might have a hard time understanding the LGPL correctly. Ian Lynagh wrote: > I'll be looking at making it optional once 6.8.1 is out of the way, but > you will need to use a GHC compiled with an alternative; you won't be > able to make a non-GMP program with a GMP GHC. > Thanks, that's good news. Perhaps one option for the non-GMP version of GHC would be to have a large integer library written in Haskell itself, since it is useful to have large integers even if they are not as fast as those provided by GMP (eg when writing a lexer it is useful to have large integers to correctly lex integer literals (ie without silently truncating them to the capacity of an Int) but speed here is not that important). To get high speed for stuff in external libs, perhaps some way of extending the foreign interface to allow direct access to the Haskell heap instead of always having to copy via the C heap, would be useful. Duncan Coutts wrote: > Sounds to me like the simlest solution for you would be if GHC could use > a dynamically linked gmp.dll on Windows. That also sounds like much less > work that replacing gmp completely. This would certainly make things easier though it doesn't solve every problem. For example, the LGPL requires you to give permission to people to reverse engineer your application, in order for them to be able to understand it enough to get it to work with an updated version of the LGPL component. Although this is perfectly reasonable imho, it leaves me with a problem if my application also needs to make use of eg Microsoft runtime components or third party proprietary statically linked libraries since there are parts of my program binary for which I do not have the authority to grant permission to reverse engineer thus it may not even be possible for me to comply with the terms of the LGPL. Of course I am not a lawyer so I may have got this wrong, but since I can't possibly afford to hire a lawyer to look into all of this I have to play it safe and therefore would prefer to avoid any use of LGPL components in a proprietary app. Thanks also to everyone else who replied, Brian. From duncan.coutts at worc.ox.ac.uk Thu Aug 16 10:27:57 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 16 10:18:14 2007 Subject: Status of GHC runtime dependency on GNU multi precision arithmetic library In-Reply-To: <46C44F7C.5020003@metamilk.com> References: <46C33AE1.9080601@metamilk.com> <20070815183309.GD3020@localhost.localdomain> <46C44F7C.5020003@metamilk.com> Message-ID: <1187274477.24215.181.camel@localhost> On Thu, 2007-08-16 at 14:22 +0100, Brian Hulley wrote: > > Sounds to me like the simlest solution for you would be if GHC could use > > a dynamically linked gmp.dll on Windows. That also sounds like much less > > work that replacing gmp completely. > This would certainly make things easier though it doesn't solve every > problem. For example, the LGPL requires you to give permission to people > to reverse engineer your application, in order for them to be able to > understand it enough to get it to work with an updated version of the > LGPL component. Although this is perfectly reasonable imho, it leaves me > with a problem if my application also needs to make use of eg Microsoft > runtime components or third party proprietary statically linked > libraries since there are parts of my program binary for which I do not > have the authority to grant permission to reverse engineer thus it may > not even be possible for me to comply with the terms of the LGPL. >From the LGPL v3: You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: [list of stuff you have to do] So it looks like you only have not restrict reverse engineering for the purposes of making updated GMP libs work with your program. Since the MS Runtime components do not interact directly with the GMP at all you shouldn't need to grant users the right to reverse engineer those components. Indeed it's only ghc library and rts code that would interact with gmp.dll. BTW, I don't think it should be too hard to construct a notice that indicates that portions of the work are covered by specific copyright licences, the details of which are available. After all Microsoft have dozens of these notices for various bits of BSD code they use and nobody mistakes Windows for Free software. From alistair at abayley.org Thu Aug 16 11:13:08 2007 From: alistair at abayley.org (Alistair Bayley) Date: Thu Aug 16 11:04:40 2007 Subject: -optl doesn't seem to pass to ld (on Windows) Message-ID: <79d7c4980708160813r6d9306c2wac6be1a46e795fe6@mail.gmail.com> -optl--enable-stdcall-fixup With ghc-6.6.1 on WinXP, I want to pass --enable-stdcall-fixup (or --disable-stdcall-fixup, depending on my mood) to ld, but either the -optl option doesn't seem to work, or I've misunderstood what it's meant to do. ghc -v indicates that it is not in the parameters passed to ld.exe. Alistair From sof at galois.com Thu Aug 16 11:17:49 2007 From: sof at galois.com (Sigbjorn Finne) Date: Thu Aug 16 11:09:27 2007 Subject: -optl doesn't seem to pass to ld (on Windows) In-Reply-To: <79d7c4980708160813r6d9306c2wac6be1a46e795fe6@mail.gmail.com> References: <79d7c4980708160813r6d9306c2wac6be1a46e795fe6@mail.gmail.com> Message-ID: <46C46A9D.4060900@galois.com> There's another level of indirection to punch through (the gcc driver); try -optl-Wl,--enable-stdcall-fixup --sigbjorn Alistair Bayley wrote: > -optl--enable-stdcall-fixup > > With ghc-6.6.1 on WinXP, I want to pass --enable-stdcall-fixup (or > --disable-stdcall-fixup, depending on my mood) to ld, but either the > -optl option doesn't seem to work, or I've misunderstood what it's > meant to do. ghc -v indicates that it is not in the parameters passed > to ld.exe. > > Alistair > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From conal at conal.net Thu Aug 16 11:50:08 2007 From: conal at conal.net (Conal Elliott) Date: Thu Aug 16 11:41:40 2007 Subject: Change to deriving in 6.7 ?? Message-ID: I'm running ghc-6.7.20070802 and getting a new error message that didn't show up with ghc-6.6. Code: -- | Pairing for unary type constructors. newtype Pair1 f g a = Pair1 {unPair1 :: (f a, g a)} deriving (Eq, Ord, Show) Error message: src/Data/Tupler.hs:26:0: No instances for (Show (g a), Show (f a)) arising from the 'deriving' clause of a data type declaration at src/Data/Tupler.hs:(26,0)-(27,25) Possible fix: add an instance declaration for (Show (g a), Show (f a)) When deriving the instance for (Show (Pair1 f g a)) Has there been a change to "deriving"? Is there a workaround? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070816/d8b2ddf9/attachment.htm From peter.ilberg at gmail.com Thu Aug 16 15:26:45 2007 From: peter.ilberg at gmail.com (Peter Ilberg) Date: Thu Aug 16 15:18:48 2007 Subject: Display problem with ghci (:e) and vim In-Reply-To: <20070810200624.GA22871@gmx.de> References: <20070810200624.GA22871@gmx.de> Message-ID: On Fri, 10 Aug 2007, Marc Weber wrote: [...] > Do you see a lot of control structures scattering around? > > The way you get them when using !vim within vim? > (you can still use :q! do quit) No control structures. The bottom part of the file is not displayed. Also, when I open a second window (:help), the modeline/divider isn't displayed and other things aren't quite right either. When I refresh with Ctrl-L, the cursor always ends up in the lower right corner on the last displayed character instead of where it used to be. > your TERMINAL env var might be important. > Does it look different when additionally running all within screen? > > Perhaps :h terminal* can also help? Thanks for the :h terminal hint. I didn't know about that. Unfortunately, I had looked at the TERM and TERMCAP settings before. I found only one difference compared to running in a shell or within hugs, but it didn't fix the problem (nor did it break hugs when I tried the opposite). There may be other differences, but I can't see them since vim's display is messed up (:set termcap doesn't display all of the settings as it does when I run vim by itself). Oh well, I'll just stick to hugs for now. -- Peter From peter at syncad.com Thu Aug 16 15:35:33 2007 From: peter at syncad.com (Peter Hercek) Date: Thu Aug 16 15:27:15 2007 Subject: hyperlinked haskell 98 grammar In-Reply-To: <404396ef0708160612p518faf5di15335d89a6d124f4@mail.gmail.com> References: <404396ef0708160609v18b5b6d7s58c6ea43417d34c6@mail.gmail.com> <404396ef0708160612p518faf5di15335d89a6d124f4@mail.gmail.com> Message-ID: <46C4A705.4080703@syncad.com> Hi Neil, For haskell-cafe members: This is what we are talking about: http://www.hck.sk/users/peter/ I'm glad somebody liked it. I do not understand what you mean by the extension request. Would you want to see the number of references of a production head even without opening the popup list box? If you meant that the pop-up list box should always display all backward links directly (without a scroll bar) then it would not work for a very big number of such links (in theory there can be hundreds there). If you do not like the default of 5 then change the nMaxRowCount "constant". Anyway, if it is complicated to describe, let it be. I do not expect to play with the java script code much. Only the most trivial things have a chance to be implemented by me. I have written the java script code few years ago and I do not really like java script ... Just wanted to give back something to the community - so I added the Haskell specific data. As for as putting it on the Haskell org I do not mind if somebody else does it. Although I'm not that sure if it would require license change. If I would believe giving it into public domain would make more grammars browsable like this one then I would do it. I do not really expect heavy loads. From my experience most language users never ever look at the grammar nor they care about it. And those who consult it a lot will take a local copy and tweak it anyway. Looking at the munin server loads, looks like you and Esa are the only ones who actually checked it out :-D Anyway, sending this to haskell cafe too (as recommended). I expect a discussion (if any) will continue there. Sorry about GHC user list abuse. Peter Hercek. Neil Mitchell wrote: > Hi > > In addition, perhaps this should be relocated to haskell.org, if your > server is not suitable for a large volume of users. I think it should > also be integrated somewhere (perhaps a link from the HTML report, and > certainly on the wiki) > > Thanks > > Neil > > On 8/16/07, Neil Mitchell wrote: >> Hi Peter, >> >> A nice application. One suggestion: I would have implemented it so >> that a maximum on one backward hyperlink menu could be visible at once >> - try clicking on two RHS's and you'll get too "menus" visible at the >> same time. >> >> You also might want to mail this out on haskell-cafe - which is more >> appropriate for "general haskell" things, ghc-users is more for direct >> issues with GHC (although haskell-cafe can also be used for those) >> >> Thanks >> >> Neil >> >> On 8/16/07, Peter Hercek wrote: >>> Hi, >>> >>> I was improving my Haskell knowledge lately and I created a small dhtml application which allows browsing of >>> Haskell 98 grammar. I contains both forward and backward hyperlinks. By backward hyperlink I mean that you can >>> click on an a production head and you get a popup list box where you can navigate to any production using the >>> nonterminal. If you like it please save and use your local copy since the server cannot handle much load. >>> >>> http://www.hck.sk/users/peter/ >>> >>> Peter. >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> From brianh at metamilk.com Thu Aug 16 17:55:25 2007 From: brianh at metamilk.com (Brian Hulley) Date: Thu Aug 16 17:46:30 2007 Subject: Status of GHC runtime dependency on GNU multi precision arithmetic library In-Reply-To: <1187274477.24215.181.camel@localhost> References: <46C33AE1.9080601@metamilk.com> <20070815183309.GD3020@localhost.localdomain> <46C44F7C.5020003@metamilk.com> <1187274477.24215.181.camel@localhost> Message-ID: <46C4C7CD.1010705@metamilk.com> Duncan Coutts wrote: > On Thu, 2007-08-16 at 14:22 +0100, Brian Hulley wrote: >> .. For example, the LGPL requires you to give permission to people >> to reverse engineer your application... thus it may >> not even be possible for me to comply with the terms of the LGPL. >> > > >From the LGPL v3: > > You may convey a Combined Work under terms of your choice that, > taken together, effectively do not restrict modification of the > portions of the Library contained in the Combined Work and > reverse engineering for debugging such modifications, if you > also do each of the following: > [list of stuff you have to do] > > So it looks like you only have not restrict reverse engineering for the > purposes of making updated GMP libs work with your program. Since the MS > Runtime components do not interact directly with the GMP at all you > shouldn't need to grant users the right to reverse engineer those > components. Indeed it's only ghc library and rts code that would > interact with gmp.dll. > Thanks for suggesting that. It sounds reasonable though I tend to get a bit paranoid when it comes to legal things - will the FSF agree with the above interpretation etc. > BTW, I don't think it should be too hard to construct a notice that > indicates that portions of the work are covered by specific copyright > licences, the details of which are available. After all Microsoft have > dozens of these notices for various bits of BSD code they use and nobody > mistakes Windows for Free software. True, but if there's any chance of just getting rid of the GMP altogether from a version of GHC there would be no tricky issues when it comes to distributing proprietary apps, thus potentially increasing GHC's user base, making Haskell more popular, and hopefully leading to more BSD3 libs being written by those new users... ;-) Best regards, Brian. From sof at galois.com Thu Aug 16 23:48:36 2007 From: sof at galois.com (Sigbjorn Finne) Date: Thu Aug 16 23:40:11 2007 Subject: ANNOUNCE: Bamse 1.0 Message-ID: <46C51A94.9090401@galois.com> Galois is pleased to announce the first public release of Bamse, a Windows Installer creator framework written in Haskell. Using Bamse, you can easily create applications that let you build Windows Installer (MSIs) for your project's product deliverables. The tool was written quite a while ago (4-5 years) as an internal tool at Galois to help the automated building of shippable bundles for Windows platforms, but has also been used for GHC installers since version 5.0.x (and other Haskell-related tools, interpreters and packages.) The source code + support package is available from http://galois.com/~sof/bamse/ Remarks/notes: - the source code is covered by a BSD license. - questions, bug reports to sof@galois.com / sof@forkIO.com (*) - If someone would like to adopt and extend the code to make it even more useful, feel free to dive in and hack. (Integrate it into the building of Cabal source and binary dists, perhaps..?) - If there's genuine interest, the code could be made available via a repo ( (*) being the main reason not to right now.) Enjoy --sigbjorn (*) - I'm in the middle of moving to another tectonic plate, so e-mail responses might be slower than usual for the next couple of weeks. From eivuokko at gmail.com Fri Aug 17 03:07:36 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Fri Aug 17 02:59:07 2007 Subject: ANNOUNCE: Bamse 1.0 In-Reply-To: <46C51A94.9090401@galois.com> References: <46C51A94.9090401@galois.com> Message-ID: Hi, On 8/17/07, Sigbjorn Finne wrote: > > Galois is pleased to announce the first public release of Bamse, > a Windows Installer creator framework written in Haskell. Using > Bamse, you can easily create applications that let you build > Windows Installer (MSIs) for your project's product deliverables. > > The tool was written quite a while ago (4-5 years) as an internal > tool at Galois to help the automated building of shippable bundles > for Windows platforms, but has also been used for GHC installers > since version 5.0.x (and other Haskell-related tools, interpreters > and packages.) Cool :-) I wish I had known this was coming - I've been working recently on MSI generator for pre-compiled Cabal-packages, but it uses Wix tools, instead of foreign bindings to MSI interfaces. > The source code + support package is available from > > http://galois.com/~sof/bamse/ > > Remarks/notes: > - the source code is covered by a BSD license. > - questions, bug reports to sof@galois.com / sof@forkIO.com (*) > - If someone would like to adopt and extend the code to make > it even more useful, feel free to dive in and hack. (Integrate > it into the building of Cabal source and binary dists, perhaps..?) > - If there's genuine interest, the code could be made available > via a repo ( (*) being the main reason not to right now.) Best regards, Esa From Christian.Maeder at dfki.de Fri Aug 17 06:53:11 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Aug 17 06:44:48 2007 Subject: Qualified identifiers opinion In-Reply-To: <46C382A9.5010107@charter.net> References: <46C382A9.5010107@charter.net> Message-ID: <46C57E17.5030900@dfki.de> Hi Isaac, just to give you a reply at all, see below. I reply glasgow-haskell-users@haskell.org since I'm not subscribed to haskell-prime. And I don't want to subscribe, because I'm more interested that Haskell becomes more stable (and standard). So here is my opinion: 1. The lexer should recognize keywords. 2. I would not mind if Haskel98 rejected all keywords that are also rejected by extensions, so that the lexer is extension independent. (Starting with Haskell98, removing conflicting identifiers as soon as I switch on valuable extensions does not make sense.) 3. I'm against qualified identifiers, with the unqualified part being a keyword like "Foo.where". (The choice of qualification should be left to the user, usually one is not forced to used qualified names.) 4. However, "Foo.where" should always be rejected and not changed to "Foo.wher e"! (Longest matching, aka "maximal munch", must not consider keywords!) (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) I would not mind if a name "F. " is plainly rejected. It only makes sense, when a data constructor is the first argument of the composition operator "(.)" Maybe "." and "$" as operators should require white spaces on both sides, since "$(" also indicates template haskell. Cheers Christian Isaac Dupree wrote: > > Especially after writing a partial lexer for Haskell, I opine that this > should be all legal: > > > > module Foo where > > --in case you didn't know, this is legal syntax: > Foo.f = undefined > > Foo.mdo = undefined > Foo.where = undefined > x Foo.! y = undefined > x Foo... y = undefined --remember ".." is reserved id, e.g. [2..5] > > > {-# LANGUAGE RecursiveDo, BangPatterns #-} module Bar where > import Foo > hello !x = mdo { y <- Foo.mdo Foo... ({-Foo.-}f x y); return y } > > {- Haskell 98 -} module Baz where > import Foo > goodbye x = x ! 12 > > > > (Foo.where) lexing as (Foo.wher e) or (Foo . where) does not make me > happy. (being a lexer error is a little less bad...) Especially not > when the set of keywords is flexible. I don't see any good reason to > forbid declaring keywords as identifiers/operators, since it is > completely unambiguous, removes an extension-dependence from the lexer > and simplifies it (at least the mental lexer); Also I hear that the > Haskell98 lexing is (Foo.wher e), which I'm sure no one relies on... > > Well, that's my humble opinion on what should go into Haskell' on this > issue. > > Isaac From mechvel at botik.ru Fri Aug 17 09:10:30 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Aug 17 09:01:58 2007 Subject: where to take ghc-6.8(.1) Message-ID: <20070817131030.GA18711@scico.botik.ru> Yan Linah wrote about testing ghc-6.8(.1). Please, where to take its source from? If it is CVS, then, please, specify the command. Is it with profiling? ----------------- Serge Mechveliani mechvel@botik.ru From stefanor at cox.net Fri Aug 17 14:44:39 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Aug 17 14:36:08 2007 Subject: Qualified identifiers opinion In-Reply-To: <46C57E17.5030900@dfki.de> References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de> Message-ID: <20070817184439.GA3189@localhost.localdomain> On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote: > Hi Isaac, > > just to give you a reply at all, see below. I reply > glasgow-haskell-users@haskell.org since I'm not subscribed to > haskell-prime. And I don't want to subscribe, because I'm more > interested that Haskell becomes more stable (and standard). So here is > my opinion: > > 1. The lexer should recognize keywords. > > 2. I would not mind if Haskel98 rejected all keywords that are also > rejected by extensions, so that the lexer is extension independent. > (Starting with Haskell98, removing conflicting identifiers as soon as I > switch on valuable extensions does not make sense.) > > 3. I'm against qualified identifiers, with the unqualified part being a > keyword like "Foo.where". (The choice of qualification should be left to > the user, usually one is not forced to used qualified names.) > > 4. However, "Foo.where" should always be rejected and not changed to > "Foo.wher e"! (Longest matching, aka "maximal munch", must not consider > keywords!) > > (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) > > I would not mind if a name "F. " is plainly rejected. It only makes > sense, when a data constructor is the first argument of the composition > operator "(.)" > > Maybe "." and "$" as operators should require white spaces on both > sides, since "$(" also indicates template haskell. What's wrong with the status quo? Our current lexical rules *seem* complicated to newbies, but just like everything else in Haskell it carries a deep simplicity; having only one rule (maximal-munch) gives a certain elegance that the proposals all lack. I'd hate to see Haskell become complex all the way down just to fix a few corner cases; I see this pattern of simplicity degerating through well-intentioned attempts to fix things all over the language... Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070817/79c0c437/attachment.bin From seth at cql.com Fri Aug 17 15:40:06 2007 From: seth at cql.com (Seth Kurtzberg) Date: Fri Aug 17 15:32:34 2007 Subject: Qualified identifiers opinion In-Reply-To: <20070817184439.GA3189@localhost.localdomain> References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de> <20070817184439.GA3189@localhost.localdomain> Message-ID: <005a01c7e106$69a9d660$3cfd8320$@com> -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Stefan O'Rear Sent: Friday, August 17, 2007 2:45 PM To: Christian Maeder Cc: Haskell Prime; GHC Users Mailing List; Isaac Dupree Subject: Re: Qualified identifiers opinion On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote: > Hi Isaac, > > just to give you a reply at all, see below. I reply > glasgow-haskell-users@haskell.org since I'm not subscribed to > haskell-prime. And I don't want to subscribe, because I'm more > interested that Haskell becomes more stable (and standard). So here is > my opinion: > > 1. The lexer should recognize keywords. > > 2. I would not mind if Haskel98 rejected all keywords that are also > rejected by extensions, so that the lexer is extension independent. > (Starting with Haskell98, removing conflicting identifiers as soon as > I switch on valuable extensions does not make sense.) > > 3. I'm against qualified identifiers, with the unqualified part being > a keyword like "Foo.where". (The choice of qualification should be > left to the user, usually one is not forced to used qualified names.) > > 4. However, "Foo.where" should always be rejected and not changed to > "Foo.wher e"! (Longest matching, aka "maximal munch", must not > consider > keywords!) > > (see end of: > http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) > > I would not mind if a name "F. " is plainly rejected. It only makes > sense, when a data constructor is the first argument of the > composition operator "(.)" > > Maybe "." and "$" as operators should require white spaces on both > sides, since "$(" also indicates template haskell. What's wrong with the status quo? Our current lexical rules *seem* complicated to newbies, but just like everything else in Haskell it carries a deep simplicity; having only one rule (maximal-munch) gives a certain elegance that the proposals all lack. I'd hate to see Haskell become complex all the way down just to fix a few corner cases; I see this pattern of simplicity degerating through well-intentioned attempts to fix things all over the language... Stefan I agree with Stefan, for the reasons he stated and for one additional reason: There would be a multitude of unintended behavior changes. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface From isaacdupree at charter.net Fri Aug 17 16:48:18 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 17 16:40:30 2007 Subject: Qualified identifiers opinion In-Reply-To: <46C57E17.5030900@dfki.de> References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de> Message-ID: <46C60992.5010503@charter.net> Christian Maeder wrote: > Hi Isaac, > > just to give you a reply at all, see below. I reply > glasgow-haskell-users@haskell.org since I'm not subscribed to > haskell-prime. And I don't want to subscribe, because I'm more > interested that Haskell becomes more stable (and standard). Then maybe you can join haskell-prime and provide the energy that rounds up all the little fixes and tries to actually produce the thing! Drastic changes are not intended to go in. Haskell' should bring more stability and standardness (as long as it doesn't diverge too much from Haskell98, which would decrease stability and standardness) > So here is > my opinion: > > 1. The lexer should recognize keywords. > > 2. I would not mind if Haskel98 rejected all keywords that are also > rejected by extensions, so that the lexer is extension independent. > (Starting with Haskell98, removing conflicting identifiers as soon as I > switch on valuable extensions does not make sense.) Trouble is, extensions are just that: extensions, and more with their own keywords may be added in the future! unless we want an internet-standard-like "x-keywordname" - but that doesn't solve this problem: standardized new keyword names clogging up the general namespace, as long as they don't have a symbol (like Objective-C has @class, @whatever...). > 3. I'm against qualified identifiers, with the unqualified part being a > keyword like "Foo.where". (The choice of qualification should be left to > the user, usually one is not forced to used qualified names.) > > 4. However, "Foo.where" should always be rejected and not changed to > "Foo.wher e"! (Longest matching, aka "maximal munch", must not consider > keywords!) > > (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) > > I would not mind if a name "F. " is plainly rejected. It only makes > sense, when a data constructor is the first argument of the composition > operator "(.)" I wouldn't mind if that was banned either. That case needs to be considered for implementing my lexer. In fact, banning that and qualified keywords allows the lexer proper not to know keywords and nevertheless ban qualified keywords (a bit of a hack). But... while I wouldn't _recommend_ using qualified keywords, and compilers could give a warning even for haskell98 code that uses known extension-keyword-names at all, it seems best to me, to _allow_ them, in the interests of allowing code to remain fairly stable with the potential of extensions being developed (especially thinking of the BangPatterns that had an effect on existing definitions of (!) ). > > Maybe "." and "$" as operators should require white spaces on both > sides, since "$(" also indicates template haskell. but it's so convenient as it is... plenty of code uses (.) without spaces, and I don't like the way template-haskell steals "$(" and "$id" (from the point of view of a person who has never tried to use template-haskell). I think haskell is more stable by allowing existing code e.g. (f = fix (\rec -> .... rec ....) --'rec' is arrow-sugar keyword than banning some bunch of new keyword names. And allowing interim interoperability with old code that exports those names, like the unfortunate (!) or (.) (I know, those aren't exactly ever keywords/syms) seems like a good idea when it removes complexity rather than adding it. I don't want Haskell98 to become a language that has difficulty interoperating with libraries and using-applications that use newer Haskells. from other comments: >> What's wrong with the status quo? Our current lexical rules *seem* >> complicated to newbies, but just like everything else in Haskell it carries >> a deep simplicity; having only one rule (maximal-munch) gives a certain >> elegance that the proposals all lack. >> >> I'd hate to see Haskell become complex all the way down just to fix a few >> corner cases; I see this pattern of simplicity degerating through >> well-intentioned attempts to fix things all over the language... > > I agree with Stefan, for the reasons he stated and for one additional > reason: There would be a multitude of unintended behavior changes. Well, GHC doesn't implement aforementioned maximal-munch re: keywords. I don't think it's good (compositional?) design for the set of keywords to be part of the lexer rather than a pass after it, when keywords behave so similarly to other words, and also when there are non-keywords like "as" and "qualified" and sometimes "forall" (whose non-reserved status I support). lex --> keywords --> layout --> parse Besides, I don't think any of the above proposals will generate behavior changes in real code. Some cause more errors (adding more keywords; banning adjacent '.' or '$') and some allow a few more things that were errors before. f = Just.let x = x in id --a.k.a. f = Just would break in my proposal, but it also breaks according to Haskell98... Isaac From isaacdupree at charter.net Sat Aug 18 07:00:10 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Aug 18 06:52:29 2007 Subject: Qualified identifiers opinion In-Reply-To: <46C57E17.5030900@dfki.de> References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de> Message-ID: <46C6D13A.5030409@charter.net> Christian Maeder wrote: | 3. I'm against qualified identifiers, with the unqualified part being a | keyword like "Foo.where". (The choice of qualification should be left to | the user, usually one is not forced to used qualified names.) Okay, here's a thought experiment... one may follow along, and agree or not as one likes (I'm not sure how much I agree with it myself, though it might be an interesting way to structure a compiler) > {-# LANGUAGE ForeignFunctionInterface #-} > module Foo where Suppose all modules have an implicit, unavoidable > import ":SpecialSyntax" (module, where, let, [], -- ... > , foreign --because that extension is enabled > ) Now let's import some imaginary already-existing modules that use "keywords" > import A (foreign) > import B (mdo) This turns up a problem already: explicitly naming things in an import or export list might not work unambiguously, because keywords are sometimes used to mean special things there. Going on... maybe we imported the whole modules. According to standard Haskell import rules, there is no conflict until the ambiguous word is used. Either "f" here works fine, because ":SpecialSyntax" in this module did not import "mdo": > f = mdo > f = B.mdo Whereas the possibilities with "foreign"... > g = foreign --error, ambiguous!!!! > foreign import ccall ........ --error, ambiguous!!!! > g = A.foreign --okay, unambiguous > ":SpecialSyntax".foreign import ccall .... -- can't write in Haskell! Now, if we want to avoid the understandably undesirable matter of imports interfering with keywords (after all, keywords can appear before the import list is finished, such as "module" "where" and "import"), we could tweak the import-conflict rules for this special case. In this module where "foreign" is imported from ":SpecialSyntax", the mere phrase "import A" could raise an error, as if all imported syntax were used (unqualified, as always) in the module. Whereas, "import qualified A" would not. (and what about "import A hiding ..."?) By the way, we are lucky that pragmas have their own namespace {-# NAME arguments #-}. But as I mentioned, we lack a namespace for extensions that have a semantic impact on the annotated code. Certain preprocessors invent things like {-! !-} ... or add template-haskell syntax, or some arbitrary other keywords syntax like "proc...do"... or even steal large portions of existing comment syntax (Haddock, which isn't even a semantic impact on the code!) BTW #2: The simpler and less variable the lexer is, the easier it is to scan for LANGUAGE pragmas. That search doesn't need to deal with keywords at all. (although it may be popular not to use the usual lexer in order to search for those pragmas, I don't know) Isaac From peter at syncad.com Sun Aug 19 09:39:38 2007 From: peter at syncad.com (Peter Hercek) Date: Sun Aug 19 09:31:12 2007 Subject: hyperlinked GHC v6.6 grammar (just syntax part) Message-ID: Brandon Michael Moore wrote: > How hard is it to make another grammar? It would be very nice if parser > generators could make a page like this. Have you seen the program > BNFC (The BNF Converter)? It tries to generate some nicely-formatted > TeX documentation of the grammar, this could be even more useful. It is not complicated provided that I have a nicely formated EBNF grammar to start with. I agree it would be great if parser generators do this, but there may not be enough interest and I do not have time to do it all myself. I can provide assistance and some code to start with though. Could be worth a license change too. ANTLR generated a hyperlinked grammar description when generating a parser but it does not contain the backward links. When I contacted the authors there was not really an interest there. I checked out the BNFC report. Looks interesting. Though, it was not clear from it whether one can generate hyperlinked html version of the grammar from the TeX source. Do you know it? > No worries there, if there's anything to be sorry about it's depriving > people not on ghc-users of such a nifty. If you really want to apologize > you could make another with the grammar of GHC Haskell :) I added GHC v6.6 grammar. Only the syntax. Check http://www.hck.sk/users/peter/ and the notes at the end of the grammar to see what was changed. Peter. From igloo at earth.li Sun Aug 19 18:19:02 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Aug 19 18:10:25 2007 Subject: where to take ghc-6.8(.1) In-Reply-To: <20070817131030.GA18711@scico.botik.ru> References: <20070817131030.GA18711@scico.botik.ru> Message-ID: <20070819221902.GA27147@matrix.chaos.earth.li> Hi Serge, On Fri, Aug 17, 2007 at 05:10:30PM +0400, Serge D. Mechveliani wrote: > Yan Linah wrote about testing ghc-6.8(.1). > Please, where to take its source from? > If it is CVS, then, please, specify the command. The 6.8 branch hasn't been forked yet. It will be forked from the HEAD at some point. If you want to try out the HEAD in the mean time then see http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories and http://hackage.haskell.org/trac/ghc/wiki/Building > Is it with profiling? I'm not sure what you mean; bindists of the HEAD are made nightly (when the build works, at least), available from: http://www.haskell.org/ghc/dist/current/dist/ and I'm fairly sure they all include profiling libraries. Thanks Ian From Christian.Maeder at dfki.de Mon Aug 20 04:26:58 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Aug 20 04:18:19 2007 Subject: Qualified identifiers opinion In-Reply-To: <20070817184439.GA3189@localhost.localdomain> References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de> <20070817184439.GA3189@localhost.localdomain> Message-ID: <46C95052.405@dfki.de> Stefan O'Rear wrote: > What's wrong with the status quo? Our current lexical rules *seem* > complicated to newbies, but just like everything else in Haskell it > carries a deep simplicity; having only one rule (maximal-munch) gives a > certain elegance that the proposals all lack. I'm quite in favour of "maximal munch", but after munching "Foo." or "Foo.where" saying: Sorry I've munched too much, I meant to munch only "Foo" and "." (because Foo is a data constructor) or "Foo.wher" and "e" (because "where" is a keyword) carries "simplicity", to "deep" for me. Cheers Christian From Christian.Maeder at dfki.de Mon Aug 20 04:59:09 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Aug 20 04:50:48 2007 Subject: Qualified identifiers opinion In-Reply-To: <46C95052.405@dfki.de> References: <46C382A9.5010107@charter.net> <46C57E17.5030900@dfki.de> <20070817184439.GA3189@localhost.localdomain> <46C95052.405@dfki.de> Message-ID: <46C957DD.7050602@dfki.de> Christian Maeder wrote: > Stefan O'Rear wrote: >> What's wrong with the status quo? Our current lexical rules *seem* >> complicated to newbies, but just like everything else in Haskell it >> carries a deep simplicity; having only one rule (maximal-munch) gives a >> certain elegance that the proposals all lack. > > I'm quite in favour of "maximal munch", but after munching "Foo." or > "Foo.where" saying: > > Sorry I've munched too much, I meant to munch only "Foo" and "." > (because Foo is a data constructor) or "Foo.wher" and "e" (because > "where" is a keyword) > > carries "simplicity", to "deep" for me. Apologies, if the above sounded rude. In fact, I just realized that the tokenizer can decide what to do with "Foo." or "Foo.wher" when seeing the next character. However, it is not helpful at all, when the lexer passes "Foo.wher" and "e" to the type checker. The programmers's input deserves more respect. C. From simonpj at microsoft.com Mon Aug 20 06:04:16 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Aug 20 05:55:37 2007 Subject: wondering about -ddump-parsed, rn In-Reply-To: <46BAE390.5020001@charter.net> References: <46BA5553.803@charter.net>