- Glasgow-haskell-users

RE: Quick question re RULES
by Simon Peyton-Jones 02 Nov '00

02 Nov '00

| PrelBase contains the appended code. Am I correct in | assuming that the stuff is structured as it is, because the | "map" rule first `breaks' the map `open', which exposes it | to the various foldr/build rules, and if no foldr/build rule | matches, the "mapList" rule `closes' it again in a later | phase of optimisation - after build was inlined? If so, it | seems like the whole thing depends a bit on the timing of | the various optimsations (the map might be closed again | before any of the foldr/build rules fires). Is this maybe | the reason that build has an INLINE 2 pragma, which delays | its inlining, and thus, the closing of the map? That's exactly it. | All very cunning, it seems ;-) A bit too cunning for comfort. I wish I could think of a better way to expose map's impl using build without paying a price for doing so if it turns out not to fuse with anything. But so far I've failed to do so. Is this a propos of your new transformations for parallelism? Simon

2 1

Fun with GHC's optimiser
by Manuel M. T. Chakravarty 02 Nov '00

02 Nov '00

Questions over questions arise in my quest to understand GHC's code generator. In this nice little piece of STG $w$snewPArray = NO_CCS[] \r[ww w] case newIntArray# [ww realWorld#] of wild { (#,#) s2# mba# -> case -# [ww 1] of y { DEFAULT -> let { wild1 = NO_CCS I#! [ww]; } in case ># [0 y] of wild2 { True -> PArray [wild1 mba#]; False -> let { $wgo2 = NO_CCS[] \r[y1 y2] let { a = NO_CCS PArray! [wild1 mba#]; } in case w of wild3 { I# e# -> case writeIntArray# [mba# y1 e# y2] of s2#1 { DEFAULT -> case ==# [y1 y] of wild11 { True -> (#,#) [s2#1 a]; False -> case +# [y1 1] of stg_c2aL { DEFAULT -> $wgo2 stg_c2aL s2#1 }; } }; }; } in case $wgo2 0 s2# of wild3 { (#,#) ds r -> r; }; } }; }; I am wondering whether there is a particular reason why the optimiser doesn't pull the (1) a = NO_CCS PArray! [wild1 mba#]; and the (2) case w of wild3 { I# e# -> out off the $wgo2 loop - or at least push (1) down into the True branch of `case ==# [y1 y] of'. I would say that (1) in this form pointlessly allocates heap like mad, but is only using one of the many copies of `a', namely the one allocated in the final iteration and returned to the caller. As for (2), the loop would be nice and straight if that unboxing where outside of the loop - as it is, we break the pipeline once per iteration it seems (if the branch prediction isn't very clever). Or do I misunderstand something here, or is there maybe some magic after STG that gets rid of the stuff? I attach the Haskell source, which I compiled with ghc -O -c PArrays.hs -fglasgow-exts -ddump-stg (This is 4.08.1 of course.) Also if somebody is looking at the attached source, I was wondering why, when I use the commented out code in `newPArray', I get a lot worse code (the STG code is in a comment at the end of the file). In particular, the lambda abstraction is not inlined, whereas `fill' gets inlined into the code of which the dump is above. Is it because the compiler has a lot harder time with explicit recursion than with fold/build? If so, the right RULES magic should allow me to do the same for my own recursively defined combinators, shouldn't it? Cheers, Manuel PS: Otherwise, it is quite impressive what the RULES and inliner do to the foldr that produced the above code.

1 0

Quick question re RULES
by Manuel M. T. Chakravarty 02 Nov '00

02 Nov '00

PrelBase contains the appended code. Am I correct in assuming that the stuff is structured as it is, because the "map" rule first `breaks' the map `open', which exposes it to the various foldr/build rules, and if no foldr/build rule matches, the "mapList" rule `closes' it again in a later phase of optimisation - after build was inlined? If so, it seems like the whole thing depends a bit on the timing of the various optimsations (the map might be closed again before any of the foldr/build rules fires). Is this maybe the reason that build has an INLINE 2 pragma, which delays its inlining, and thus, the closing of the map? All very cunning, it seems ;-) Cheers, Manuel -=- map :: (a -> b) -> [a] -> [b] map = mapList -- Note eta expanded mapFB :: (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst mapFB c f x ys = c (f x) ys mapList :: (a -> b) -> [a] -> [b] mapList _ [] = [] mapList f (x:xs) = f x : mapList f xs {-# RULES "map" forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs) "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f.g) "mapList" forall f. foldr (mapFB (:) f) [] = mapList f #-}

1 0

RE: ppr for Haskell Abstract Syntax
by Simon Marlow 01 Nov '00

01 Nov '00

> Hi - > I was wondering if anyone knows if there is a pretty printer > for Haskell > Abstract Syntax anywhere? I've been asking around, but > haven't located > one yet. If you know of one that I could use, it would be > really helpful! > Thanks in advance, > *Kate We have one in GHC's CVS source tree now. hslibs/hssource contains a Haskell abstract syntax, parser, and a pretty printer. It should compile on pretty much any version of GHC, but you'll probably need a recent version of Happy (1.8) for the parser. Cheers, Simon

1 0

RE: ppr for Haskell Abstract Syntax
by Simon Peyton-Jones 01 Nov '00

01 Nov '00

GHC has a pretty printer for Haskell. It's in ghc/compiler/hsSyn/*.lhs, along with the (numerous) data type declarations that define the full Haskell syntax. It would take a little work to rip it out of GHC, mind you Simon | -----Original Message----- | From: Kate S. Golder [mailto:kgolder@wellesley.edu] | Sent: 31 October 2000 21:07 | To: glasgow-haskell-users(a)haskell.org | Subject: ppr for Haskell Abstract Syntax | | | Hi - | I was wondering if anyone knows if there is a pretty printer | for Haskell | Abstract Syntax anywhere? I've been asking around, but | haven't located | one yet. If you know of one that I could use, it would be | really helpful! | Thanks in advance, | *Kate | | ********************** | Kate S. Golder | Wellesley College | Class of 2002 | | Freeman Hall | Wellesley College | Wellesley, Ma 02481 | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

AW: Using Haskell code in VBA (MS Access)?
by Lescher Christian 26 Oct '00

26 Oct '00

I tried to compile this small example with ghc-4.08.1, but it didn't work (compiling ok., but DLL does not run), while with ghc-4.05 everything is okay. What can be wrong with this? Christian Lescher > -----Urspr> üngliche Nachricht----- > Von: Sigbjorn Finne [SMTP:sof@microsoft.com] > Gesendet am: Donnerstag, 17. August 2000 20:18 > An: 'Christian Lescher' > Cc: glasgow-haskell-users(a)haskell.org > Betreff: RE: Using Haskell code in VBA (MS Access)? > > > The support libraries for HaskellDirect provide > functions for converting between BSTRs and Haskell' > String (Com.marshallBSTR, Com.unmarshallBSTR) -- > http://www.dcs.gla.ac.uk/fp/software/hdirect/user-32.html > > has the overview. However, the binaries available for > that library is for ghc-4.045, so you'd have to compile > them up yourself for ghc-4.08. > > To build a 'static' DLL, here's what you need to do: > > - compile up all your Haskell code using -static. > - write a .def file containing the entry points you > want to expose. In my example, the .def file would > just contain: > > EXPORTS > adder@8 > > - link the static DLL: > > ghc-4.05 -static --mk-dll -optdll--def=adder.def \ > -o adder.dll adder.o dllMain.o -lHSrts > > I heard some rumours that -static might disappear. If that's > the case, I think that would be unfortunate. > > --sigbjorn > > Christian Lescher <christian(a)lescher.de> writes: > > > > Thank you for your detailed answer - it's really great, it works! :-) > > > > However, I have got one more problem: the function I want to > > call from VBA is of > > type String -> String -> String > > Is there a (simple) method to convert VBA strings (BSTR) to > > Haskell's [Char] and > > vice versa? > > > > By the way: Is it possible to build DLLs that do not depend > > on GHC's runtime DLLs? > > I tried out the "-static" option like for compiling EXEs, but > > it didn't work. > > > > CL > > > > >

2 1

RE: Compiling mutually recursive modules involving instances
by Simon Peyton-Jones 26 Oct '00

26 Oct '00

| The manual also says a new, better, higher level way for | dealing with mutually recursive modules is in the works. | Is there any chance it will be ready for the next release? I don't think so. The upcoming GHCi will be the next release and it indeed gives a much better chance of doing this stuff properly. Making recursive modules possible is a high priority. But making them easy isn't as high priority as lots of other things, I'm afraid. Simon

1 0

RE: getContents
by Simon Marlow 26 Oct '00

26 Oct '00

> I don't really understand getContents. (Does anyone?) I > have some code here > (far too large to submit). If I do (on Linux, ghc4.08.1, > both with and without optimisation) > ------------------ > contents <- hGetContents handle > seq (last contents) (hClose handle) > ------------------ > the code works. However I looked at the manual and it seems > that hClose should > force the whole of contents to be read anyway. So I changed it to > ------------------ > contents <- hGetContents handle > hClose handle > ------------------ > and then the code doesn't work. If these are meant to be the > same, then we have a GHC > bug. If not, could someone explain in words of one syllable why not? > > PS - if you want the source code you'll have to download and > compile the whole of UniForM!! Using hClose on a semi-closed handle is a Bad Thing. The Haskell Report says: "Once a semi-closed handle becomes closed, the contents of the associated stream becomes fixed, and is the list of those items which were succesfully read from that handle". So I take this to mean that when you hClose a semi-closed handle, you get a random amount of data in the handle which depends on how good your compiler's strictness analyser is. yesno? Cheers, Simon

2 1

getContents
by George Russell 26 Oct '00

26 Oct '00

I don't really understand getContents. (Does anyone?) I have some code here (far too large to submit). If I do (on Linux, ghc4.08.1, both with and without optimisation) ------------------ contents <- hGetContents handle seq (last contents) (hClose handle) ------------------ the code works. However I looked at the manual and it seems that hClose should force the whole of contents to be read anyway. So I changed it to ------------------ contents <- hGetContents handle hClose handle ------------------ and then the code doesn't work. If these are meant to be the same, then we have a GHC bug. If not, could someone explain in words of one syllable why not? PS - if you want the source code you'll have to download and compile the whole of UniForM!!

2 1

RE: Compiling mutually recursive modules involving instances
by Simon Peyton-Jones 26 Oct '00

26 Oct '00

The best thing to do is never to put an instance declaration in an hi-boot file. I don't think you ever really need to. In contrast, mutual recursion of type declarations is often unavoidable. The manual should really say this Simon | -----Original Message----- | From: José Romildo Malaquias [mailto:romildo@urano.iceb.ufop.br] | Sent: 24 October 2000 16:00 | To: glasgow-haskell-users(a)haskell.org | Subject: Compiling mutually recursive modules involving instances | | | Hello. | | I am having difficulties in compiling mutually recursive | modules involving classes and instances in GHC 4.08.1. | Basicaly I am not finding how to write a .hi-boot where | I want to put classes and instances. | | Consider a program with 3 modules: M1, M2 and Main. The | sources are attached to the message. What should go | into M2.hi-boot? Would anyone write M2.hi-boot for me | so that I can learn it. | | Thanks. | | Romildo | -- | Prof. José Romildo Malaquias <romildo(a)iceb.ufop.br> | Departamento de Computação | Universidade Federal de Ouro Preto | Brasil |

2 1