- Glasgow-haskell-users

RE: -fspecialize-all or the like?
by Simon Marlow 22 Apr '02

22 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? Short answer: no. Sorry :) Simon

1 0

Re: ghc-pkg info
by Ashley Yakeley 22 Apr '02

22 Apr '02

At 2002-04-21 12:52, Sven Panne wrote: > >>>It would be nice if ghc-pkg had options to display the value >>>of $libdir or at least the given conf file. [...] > > >I had *major* pains with this for the upcoming HOpenGL release, too. :-P Right. I need to find the location of Rts.h. Ideally, I would do ghc-pkg -s rts --field="include_dirs" ...and look in each one (if there were more than one). Unfortunately that just returns "$libdir/include". It would be nice if either there were an option that expanded out the $libdir in fields, or else one that just returned $libdir. In the mean time, I'll pull it out of "ghc -v"... -- Ashley Yakeley, Seattle WA

1 0

RE: ghc-pkg info
by Simon Marlow 21 Apr '02

21 Apr '02

> It would be nice if ghc-pkg had options to display the value > of $libdir > or at least the given conf file. I'm trying to get my > Autotools configure > script to find Rts.h, and it's a bit of a pain. My current > approach is to > use "readlink -f `which ghc`" and get it from there, but that > fails with > the latest MacOS X version because it uses small shell > scripts in unusual > places instead of symlinks. 'ghc -v' will tell you the location of package.conf, which for a normal GHC install is located in $libdir. Does that help? Cheers, Simon

2 1

realloc for I/MArrays
by Hal Daume III 19 Apr '02

19 Apr '02

Any chance IArrays (or MArrays) will some day support something like: resize :: (Ix ix, IArray a e) => a ix e -> (ix,ix) -> a ix e that is faster than allocating a new array and then copying value-by-value? perhaps make the result a Maybe (a ix e) in the same way that realloc can return null if it can't get you more memory at the end or even just a simple memcpy like function so you could allocate a new array with the same index and element type and then copy directly from one to the other, like: arrcopy :: (Ix ix, IArray a e) => (ix -> ix) -> a ix e -> a ix e -> a ix e which can possibly fail if the indices for the destination don't line up with the source properly? i don't know enough about how UArrays are implemented in ghc to know if this is even reasonable, but if it's possible, can we expect to see something like this? :) - Hal -- 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

-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