June 2003 - Glasgow-haskell-users

Re: FW: how and where to {-# specialize #-} ?
by Alan Mycroft 26 Jun '03

26 Jun '03

> Something similar was proposed by the gcc folk at their recent > conference. The idea is that when you gcc -O4 your .c files, you get .o > files containing an intermediate typed SSA form. Upon linking the > program, gcc invokes a 'smart linker' which runs another pass on the > whole program. This allows for all kinds of cross-module inlining, > specialisation etc. It's interesting that they are just *proposing* this. From the dagstuhl presentation http://www.dagstuhl.de/00381 in 2000, I understood that the SGI Pro64 compiler infrastructure already did this (i.e. stored a similar intermediate code structure in the .o files). I also understood that the Pro64 compiler sources were to be GPL'd. Cheers, Alan

1 0

RE: how and where to {-# specialize #-} ?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

| > The only workaround is to define T early, | > import it into A, and specialise A.f there. | | What if A is a pre-defined module, say FiniteMap? | Then I can't change its source text. (Which isn't even there.) | (Of course, I can grab it from the source distribution.) | | It is sad that the usage of libraries containing polymorphic code | (which is a good thing, for obvious software engineering reasons) | seems to imply runtime overheads, by preventing specialisation. | I agree that it is sad. The only way around it is to ship libraries with *all* their source code (perhaps hidden in the interface file). That could be done, but it'd be Real Work s

3 2

RE: @-bindings broken in 6.0?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

There's support for more fine-grained distinctions now. We hav -fffi -fglasgow-exts -farrows -fparr (Manuel's parallel array stuff) We could add -fth (or -fTH?) if that seemed better S | -----Original Message----- | From: Ralf Hinze [mailto:ralf@informatik.uni-bonn.de] | Sent: 24 June 2003 13:42 | To: Ketil Z. Malde; Simon Peyton-Jones | Cc: John Meacham; glasgow-haskell-users(a)haskell.org | Subject: Re: @-bindings broken in 6.0? | | > I think lumping all these extensions under one switch is the | > problem. | | Yep, I agree. Would it be hard to split `-fglasgow-exts' | up? I'd greatly appreciate a more fine-grained control | here. | | Cheers, Ralf |

6 5

RE: how and where to {-# specialize #-} ?
by Simon Marlow 25 Jun '03

25 Jun '03

Alastair Reid writes: > One way of tackling it would be to change ghc so that > compilation doesn't > produce .o files containing machine code but, rather, files > containing a concise encoding of STG code. Yes, one could indeed do that. We've discussed various schemes like this in the past, and the bottom line is usually that it's a good idea but hasn't so far been compelling enough to warrant the effort it would take to implement. I will comment on one particular thing though: > This case ought to be easier because STG > code has already > had a very powerful optimizer applied to it so all that's > left is doing a good job with register allocation and pipelining. There's a lot more to do to get from STG code to fast machine code than just register allocation and pipelining. Even if we consider generating machine code from the intermediate C to be "just register allocation and pipelining", GHC does an awful lot of work to get from STG to C. The bytecode generator does a much more simplistic transformation from STG to bytecodes, but it loses many opportunities for optimisation in the process. So if one were to do something like this, the crucial decision is at what level to target the intermediate code. Something that can be directly interpreted *and* compiled to fast machine code (JITted?) would seem to be a good idea (Julian Seward was very keen on this). That would be at a level somewhat lower than STG, though. Cheers, Simon

1 0

RE: how and where to {-# specialize #-} ?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

| I am looking for some advice on | where to place specialize-pragmas for ghc | (to optimize speed - and heap usage) | | Typically I have some module A (containing polymorphic functions A.f, ..) | and a module B uses this. The interesting case is | when I want to specialize A.f (which is NOT exported) | to some types that are only defined in B | (but normally A should not know about B). | | Is there some kind of `deep specialisation' where one would say, | `specialize ALL the functions that are reachable from here'? - | or how can one get a similar effect? There are two questions here a) If module B defines a type B.T, and imports function A.f from module A can we specialise f at type B.T? b) If we specialise f at T, and f calls g, how can we specialise g at T? Unfortunately, GHC has no good way to do (a). It only specialises functions in the module being compiled, so it can't specialise f when compiling A because it can't see B.T it can't specialise f when compiling B because it can't see (all of) f It's not obvious how best to address this. Putting all of A's code in its interface file (not only f, but the things f calls), so that B can specialise it, seems a bit brutal; and f might then be specialised to the same type many times. But we can't specialise it in module A, because A can't see T. Maybe the Right Thing is some kind of whole-program specialisation, but GHC isn't set up to do that. The only workaround is to define T early, import it into A, and specialise A.f there. Relating to (b), GHC automatically does this specialisation propagation within one module, but if A.f calls A2.g (where A imports A2), then A2.g won't get automatically specialised; you'll have to add your own specialisation pragma in A2. Again this is far from ideal. One possible plan (totally unimplemented) is this: when compiling a module, dump specialisation guidance of the form A.f needs A2.g @ T or, more generally something like A.f @ t needs A2.g at [t] Now do a global analysis of all the specialization guidance info to generate SPECIALISE pragamas. Now recompile everything Simon

2 1

RE: @-bindings broken in 6.0?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

| > -farrows | | Is this switch documented somewhere? I looked through the docs in the | latest CVS version of GHC and couldn't find anything about it ... Not yet: I only put it in this week! And it's not documented yet. There are some examples, though in fptools/testsuite/tests/ghc-regress/arrows And the commit message contains many details (enclosed) Simon ---------------------------------------------- Add support for Ross Paterson's arrow notation ---------------------------------------------- Ross Paterson's ICFP'01 paper described syntax to support John Hughes's "arrows", rather as do-notation supports monads. Except that do-notation is relatively modest -- you can write monads by hand without much trouble -- whereas arrow-notation is more-or-less essential for writing arrow programs. It desugars to a massive pile of tuple construction and selection! For some time, Ross has had a pre-processor for arrow notation, but the resulting type error messages (reported in terms of the desugared code) are impenetrable. This commit integrates the syntax into GHC. The type error messages almost certainly still require tuning, but they should be better than with the pre-processor. Main syntactic changes (enabled with -farrows) exp ::= ... | proc pat -> cmd cmd ::= exp1 -< exp2 | exp1 >- exp2 | exp1 -<< exp2 | exp1 >>- exp2 | \ pat1 .. patn -> cmd | let decls in cmd | if exp then cmd1 else cmd2 | do { cstmt1 .. cstmtn ; cmd } | (| exp |) cmd1 .. cmdn | cmd1 qop cmd2 | case exp of { calts } cstmt :: = let decls | pat <- cmd | rec { cstmt1 .. cstmtn } | cmd New keywords and symbols: proc rec -< >- -<< >>- (| |) The do-notation in cmds was not described in Ross's ICFP'01 paper; instead it's in his chapter in The Fun of Programming (Plagrave 2003). The four arrow-tail forms (-<) etc cover (a) which order the pices come in (-< vs >-), and (b) whether the locally bound variables can be used in the arrow part (-< vs -<<) . In previous presentations, the higher-order-ness (b) was inferred, but it makes a big difference to the typing required so it seems more consistent to be explicit. The 'rec' form is also available in do-notation: * you can use 'rec' in an ordinary do, with the obvious meaning * using 'mdo' just says "infer the minimal recs" Still to do ~~~~~~~~~~~ Top priority is the user manual. The implementation still lacks an implementation of the case form of cmd. Implementation notes ~~~~~~~~~~~~~~~~~~~~ Cmds are parsed, and indeed renamed, as expressions. The type checker distinguishes the two.

1 0

RE: @-bindings broken in 6.0?
by Simon Peyton-Jones 24 Jun '03

24 Jun '03

Yes, I'm afraid so. With -fglasgow-exts Template Haskell captures [t| ... |] and [p| ... |] and similarly [d| and [e| for quotations. I don't think I'd fully realised that this conflicts with list comprehensions [t|t<-ts] (I remember reading a book when I was 10 featuring kids trying to decode a message that was in two parts "mac" .. and "hine". Took me ages to spot "machine".) But maybe this isn't what you found? Better syntax here would be welcome if anyone can think of some. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of John Meacham | Sent: 18 June 2003 03:24 | To: glasgow-haskell-users(a)haskell.org | Subject: @-bindings broken in 6.0? | | change in list comprehension parsing? | after I upgraded to ghc 6.0 there were some odd syntax errors on list | comprehensions which i did not get before, making sure i put spaces | between all symbols seems to fix them.. was something changed about how | they are parsed which breaks code that used to work? just curious. | John | -- | ------------------------------------------------------------------------ --- | John Meacham - California Institute of Technology, Alum. - john(a)foo.net | ------------------------------------------------------------------------ --- | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

7 6

GHC 6.0 Sparc/Solaris dist
by Simon Marlow 24 Jun '03

24 Jun '03

I've updated the Sparc/Solaris binary distribution of 6.0: this version should (hopefully) install without difficulty. Let me know if there are any problems. http://www.haskell.org/ghc/dist/6.0/ghc-6.0-sparc-sun-solaris2.tar.bz2 Cheers, Simon

1 0

RE: ghc-split accepts building 6.0 on Windows
by Simon Peyton-Jones 24 Jun '03

24 Jun '03

Sigbjorn has now fixed this in a better way: GHC now canonicalises the TMPDIR stuff internally. So it should just work in future. Thanks to Sigbjorn; and thaks to Dominic for pointing this one out. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dominic Cooney | Sent: 30 May 2003 11:46 | To: glasgow-haskell-users(a)haskell.org | Subject: ghc-split accepts building 6.0 on Windows | | My environment's TEMP and TMP are C:\temp, but for some reason, my recent | Cygwin install makes 'TEMP' and 'TMP' /cygdrive/c/temp/4; this duly gets | passed to ghc-inplace as C:\temp\4. | | Then, in libraries\base, ghc-split complains that \4 mentions a non-existent | group in a regexp: | | ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude | -#include HsBase.h -Icbits/regex -funbox-strict-fields -package-name base -O | -Rghc-timing -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi | Reference to nonexistent group in regex; marked by <-- HERE in m/"c:\temp\4 | <--HERE \ghc936.split\.c"/ at | d:\\users\\cooney\\ghc\\ghc-6.0\ghc\driver\split\ghc-split line 51, <TMPI> | line 23. | make[2]: *** [GHC/Base.o] Error 255 | | All I needed to do was editing ghc\driver\split\ghc-split so | | $Tmp_prefix = $ARGV[1] | | was instead | | ($Tmp_prefix = $ARGV[1]) =~ s/\\/\\\\/g; | | I don't know whether this habit of appending \4 is a delightful quirk of my | Cygwin install, but FWIW for other Windows Server 2k3/Cygwin users out | there... | | Dominic Cooney | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: [Gtk2hs-users] ghci-5.04.3 and ghc-6.0
by Simon Marlow 23 Jun '03

23 Jun '03

> Would it be possible to use the full hierarchical module name? > There's a much better chance of them being unique. > ie use > > __stginit_Control_Arrow > > rather than > > __stginit_Arrow > > I *assume* that information is avaliable at compile/build time. Yes, we already do this. However, in your case you had a module called "Arrow" in gtk2hs, and a module called "Arrow" in the lang package, in addition to the module "Control.Arrow" in the base package. Cheers, Simon

1 0