- Glasgow-haskell-users

-fspecialize-all or the like?
by Hal Daume III 19 Apr '02

19 Apr '02

Is there any way to get your overloaded functions to basically behave like templates in C++; i.e., by "automatically" inserting {-# SPECIALIZE ... #-} for every function, for every instance, for each type that is actually used in the program? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Question on style - Implicit parameters
by Jorge Adriano 18 Apr '02

18 Apr '02

Hi all, Lately I've found implicit parameters to be extremely usefull in many situations. The most simple and obvious is when you need to calculate some values that depend on specific parameters, in some context where these same parameters constant. There is no poblem if all the calculus are defined in the scope of those 'constant' parameters, but if you need to define functions outside their scope then you have to pass them as arguments, and sometimes that complicates type signatures. Now my question. I've end up in situations where I need to write something like --------- step :: Inst-> Train->Inst step inst train = changeInst deltaW deltaV inst where deltaW = someSemiConst1 with ?inst=inst; ?train train deltaV = someSemiConst2 with ?inst=inst; ?train train --------- Ok the problem is that both deltaV and deltaW are assigned some constants that implicitly depend on the arguments 'inst' and 'train'. Now imagine that someSemiConst1 = f n someSemiConst2 = g n for some n that also depends implicitly on 'inst' and 'train'. In this case 'n' would (could? haven't actually tried it) be calculated twice, one fro the first semiConst, another for the second. It would be nice to have something like with ?inst=inst; ?train train { deltaW = someSemiConst1 deltaV = someSemiConst2 } My solution was to define some function (deltaW, deltaV)=calculateDeltas with ?inst=inst; ?train=train And in this function I simple does (deltaW, deltaV)= (someSemiConst1, someSemiConst2) In case you're wondering, why not just call the 'step' function bounding it's context to 'inst' and 'train'. It doesn't makes much sense to me in this case, becouse the whole purpose of this function is to change a 'inst' acording to some 'train' (in fact it is beeing used in a foldl). How do you usually handle this situations? Is there an elegant solution for this? J.A.

1 1

RE: ANNOUNCE: GHC 5.03.20020410 snapshot released
by Simon Marlow 18 Apr '02

18 Apr '02

> Ralf Hinze <ralf(a)informatik.uni-bonn.de> writes: > > > BTW, does this version support rank-n types? > > IIRC the previous snapshot did. So presumably this one does > too? Yes, it does. Simon

2 1

RE: Heap profiling
by Simon Marlow 18 Apr '02

18 Apr '02

> I really like the profiling options in GHC, but I wonder if there's > any good way of improving heap profiling speed? I've tried using -i > to reduce the number of measurements, but it didn't seem to help a > lot. > > I see an order of magnitude speed degradation with heap profiling, > which is slightly annoying, since it is with large runs heap > consumption starts to become troublesome :-) > > Any tricks I ought to know about? Have you tried one of the recent snapshots? Heap profiling was overhauled significantly since the 5.02 branch, and one of the things I did was to make the -i option work better. Previously profiling was forced to use the 2-space collector, but now it can use generational collection and just force a major GC before it does a heap census. If you're stuck with 5.02.x, you can try increasing the size of the allocation area with (say) -A4m to increase the time between garbage collections. Cheers, Simon

1 0

RE: New Patches & Binary for MacOS X
by Simon Marlow 18 Apr '02

18 Apr '02

> At 2002-04-15 12:29, Wolfgang Thaller wrote: > > >The binary package for MacOS X is now available at > >http://www.kfunigraz.ac.at/imawww/haskell/GHC.dmg > > It fails to build TypedObject.hs. > > $ /usr/local/bin/ghc -fvia-C -pgmccc -pgmacc -package lang -package > concurrent -fglasgow-exts -fallow-undecidable-instances -package-name > javavm -c TypedObject.hs -o TypedObject.o +RTS -K20m > stack overflow: use +RTS -K<size> to increase it We had a problem with the typechecker looping that was fixed in CVS just prior to the 20020410 snapshot - perhaps the MacOS binary snapshot doesn't include this fix? Cheers, Simon

1 0

RE: ghc5.03 .hi and .hi-boot files don't you just love those incompatible changes?
by Simon Marlow 18 Apr '02

18 Apr '02

> Ah, I've figured it out. The new .hi-boot file format is > actually Haskell!! Well almost. > You have to fully qualify type names (you can't use Int, you > must use GHC.Base.Int) > and the input isn't run through -cpp. Yes, that's the idea. Now that we don't have an interface file parser as such, .hi-boot parsing is done by the main parser with the result that the syntax is much more Haskellish (and hence more readable). We wondered about various schemes to make the recursive module story easier, but couldn't come up with anything that was worth the effort to implement - "doing it properly" i.e. reading the Haskell source to get the type signatures and data declarations, or even allowing unqualified names in the .hi-boot file is a total swamp. Hope the new .hi-boot syntax doesn't cause you too much hassle... Cheers, Simon

1 0

RE: hsc2hs does not fail
by Simon Marlow 18 Apr '02

18 Apr '02

> for some reason hsc2hs does not fail if the automatically generated > program fails to execute. This only happends if I forget to set > LD_LIBRARY_PATH before saying make. But it leads to a confusing error > messages when an empty .hs file is left and ghc complaints > with "file name > does not match module name". > > The patch below was done against ghc-5.02.2 on FreeBSD. Committed, thanks. Simon

1 0

RE: -O2
by Simon Marlow 18 Apr '02

18 Apr '02

> In my program I observe that, with -O2 flag turned on, > Program 1 behaves > like Program 2. And without O2, their outputs are different. > > Is it the desirable behaviour? For my program, I did not expect the > optimizer to do this transformation. -O2 should not change the behaviour of the program, except where the behaviour is dependent on external factors (eg. I/O) or when the program uses unsafePerformIO. If that's not the case, could you send us the code so we can take a look? Cheers, Simon

1 0

RE: building with make -j2 ?
by Simon Marlow 18 Apr '02

18 Apr '02

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > The snapshot source distribution has now been updated to include the > > file mk/package.mk which was missing the first time around. > > Thanks. > > Btw, does ghc build with "make -j2"? I tried building the > snapshot just now with it but got a make error at some > point. I forget to save the build log, but I can easily > fire up another build if you want to see it. You should be able to use -jN in ghc/compiler (indeed, I use this regularly) but I haven't been through and fixed up the rest of the tree to work with -jN yet. Cheers, Simon

1 0

RE: handling of multibyte char strings
by Simon Marlow 18 Apr '02

18 Apr '02

> GHC 5.02.[23] seems to be quite strict about literal strings > in source code. I presume this is a feature. :-) However > this is annoying for people who want to use wide chars in > strings in source code. (Though I realise that doing so is > not very "portable".) > > To illustrate, the following program > > main :: IO () > main = > let ja = 'Japanese character' in putChar ja >> putChar '\n' > > results in > > Compiling Main ( test-ja.hs, interpreted ) > test-ja.hs:3: error in character literal > Failed, modules loaded: none. > > with both ghc and ghci. As other folk noted, you should be fine with ISO8859-1 characters but we don't have support for Unicode yet. There has been discussion at various points in the past on how to do this, and Marcin Kowalczyk has some ideas on how the Haskell interface to multi-coded text I/O should look. It is possible that we could just support UTF-8 in source files without going the whole hog and providing Unicode I/O, however. As usual, contributions are welcome :-) Cheers, Simon

1 0