January 2003 - Glasgow-haskell-users

RE: Profiling question
by Simon Marlow 06 Jan '03

06 Jan '03

> If you were using nhc98, then you could use the following: > > import NonStdProfile > > f ... = do ... > profile "point A" actionA > profile "point B" actionB > > The non-standard operation > profile :: String -> a -> a > places a labelled marker line on the profile graph at the time instant > when the value is demanded. > > I don't know whether ghc has anything similar? No, but that strikes me as rather a good idea. I'll have a go at implementing it. Cheers, Simon

1 0

RE: Suggested improvements to .hi-boot files
by Simon Marlow 06 Jan '03

06 Jan '03

Thanks for the suggestions, George. May I suggest that a good place for these things is the "Feature Requests" tracker on the GHC SourceForge page - otherwise good suggestions tend to get lost if we don't implement them immediately. > I am using .hi-boot files quite a lot at the moment. I'm > very grateful for the recent > change to a more Haskelly syntax, but I have a couple of > suggestions for the GHC team > to implement in their no doubt ample free time. 8-) > > (1) Importing a module {-# SOURCE #-} into itself currently > produces a warning, but no other action > so far as I can see. I suggest instead that this provoke a > check that the .hi-boot module accurately > reflects reality. (Otherwise there is no way of checking is > there?) Or perhaps you could add a > pragma {-# RECURSIVE #-} at the top of the module that > indicates the presence of a .hi-boot file which > should be checked. We'd like to do something like this, but there's no simple hack that gets us there quickly. One for the feature requests page. > (2) Instance declarations (with empty bodies) should be permitted. Tricky, because an instance declaration in an interface has to name the dictionary function, and currently dictionary functions are given weird internal names (that might not be the only stumbling block). But we would like to do this. > (3) There should be an option to pass .hi-boot files through > cpp. This would not be particularly useful > to me, as I have already implemented a pre-compilation phase > which does just that, but it might > be useful for others. I'd say just use Makefiles for this. > (4) The manual should recommend using say the GHCi :info > command to find out that, > say, IO must be called GHC.IOBase.IO. (If I'd known this > it'd have saved me having > to trawl through the GHC sources.) Good point. I'll add a note to the docs. > Obviously one would > ideally be able to type IO rather > than GHC.IOBase.IO, but my guess would be that this would be > (a) harder to implement than > the other suggestions, (b) less useful. We looked into this, but couldn't find an easy way to do it. > Happy New Year by the way. If any Simon is still reading, > about long have we got before the > current old library hierarchy is done away with in an > official release? Sometime before then > I will need to carry out a massive global-exchange. I'd planned to remove hslibs in the next major release, but that might prove to be too soon - especially since hslibs still contains some stuff that hasn't moved over to the hierarchy yet. So it will probably be the next-but-one major release; as usual, feedback from you folks out there is welcome. Cheers, Simon

1 0

RE: Run-time options in ghc on Linux
by Simon Marlow 06 Jan '03

06 Jan '03

> Ok, > $ cat >null.hs > module Main(main) where > main = return () > $ ghc null.hs -o null > $ ./null +RTS -? > $ Is your GHCRTS environment variable set to anything? Cheers, Simon

1 0

RE: Proposal for GHC documentation
by Simon Marlow 06 Jan '03

06 Jan '03

> > The rewritten documentation can be translated > > to HTML using just a standard xsltproc tool (available > > for both Cygwin & Linux) and XSLT DocBook stylesheet. > > The main advantage of XML version is that there is > > already developed XSLT stylesheet which generates > > input for Microsoft HTML Help Compiler. > ... > > I think that this will made GHC documentation much more easy > > for reading and browsing. > > I would strongly support such a change. Me too, I'm happy for us to move to DocBook/XML if that would give us more functionality and compatibility with existing tools, and it seems that this is the case. I imagine the updated docs will continue to work with an existing DocBook system as long as the DocBook 4 DTD is installed? If that's the case, would you like to commit your changes Krasimir? Cheers, Simon

1 0

Suggested improvements to .hi-boot files
by George Russell 06 Jan '03

06 Jan '03

I am using .hi-boot files quite a lot at the moment. I'm very grateful for the recent change to a more Haskelly syntax, but I have a couple of suggestions for the GHC team to implement in their no doubt ample free time. 8-) (1) Importing a module {-# SOURCE #-} into itself currently produces a warning, but no other action so far as I can see. I suggest instead that this provoke a check that the .hi-boot module accurately reflects reality. (Otherwise there is no way of checking is there?) Or perhaps you could add a pragma {-# RECURSIVE #-} at the top of the module that indicates the presence of a .hi-boot file which should be checked. (2) Instance declarations (with empty bodies) should be permitted. (3) There should be an option to pass .hi-boot files through cpp. This would not be particularly useful to me, as I have already implemented a pre-compilation phase which does just that, but it might be useful for others. (4) The manual should recommend using say the GHCi :info command to find out that, say, IO must be called GHC.IOBase.IO. (If I'd known this it'd have saved me having to trawl through the GHC sources.) Obviously one would ideally be able to type IO rather than GHC.IOBase.IO, but my guess would be that this would be (a) harder to implement than the other suggestions, (b) less useful. Happy New Year by the way. If any Simon is still reading, about long have we got before the current old library hierarchy is done away with in an official release? Sometime before then I will need to carry out a massive global-exchange.

1 0

RE: Template Haskell reification
by Simon Peyton-Jones 06 Jan '03

06 Jan '03

| Why is it that one can't reify top level function declarations? At the | moment it only seems that we can reify type declarations. No immediate | reason for this seems to spring to mind, but there may be one. [I'm interested to know something about your application, incidentally.] Several reasons conspire. a) Inconvenience (it's a little tiresome to implement) b) It would be particularly difficult to get the definition of a function defined in another module (because we'd have to read that entire module too). This is not true of data type declarations, which travel in interface files, so there is no ugly cross-module issue to worry about. c) I'm not quite clear what you'd expect to get. If we have f = ...f... it's easy enough. If you have mutual recursion f = ...g... g = ...f... do you get just f's definition, or g's too? If it's a pattern binding (f,g) = ... you can't avoid getting both. And even if it's a simple, non-recursive defn f = ....g.... (where g is defined earlier), I wonder whether there should be some way to get at g's definition too.

1 0

RE: Profiling question
by Simon Peyton-Jones 06 Jan '03

06 Jan '03

Not currently. It's not clear what a "point" in execution *is*! The top-level IO monad thread might provide such a point, but even then it might not be clear how much of a lazy data structure had been evaluated by that "point". I could see sense in having an I/O operation markProfile :: String -> IO () which would put a labelled vertical line on the profile to say when that "point" was. Simon | -----Original Message----- | From: Kirsten Chevalier [mailto:krc@uclink.berkeley.edu] | Sent: 03 January 2003 19:30 | To: glasgow-haskell-users(a)haskell.org | Subject: Profiling question | | Hi, | I'd like to be able to determine the percentage of allocated objects of a | particular type at specific points in a program's execution. I know that I | can use heap profiling to create a graph of memory usage broken down by type, | but is there any way to record this information at particular points in the | program (i.e., between two statements in a do-expression)? | | Thanks, | Kirsten | | -- | Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Template Haskell reification
by Sean Seefried 06 Jan '03

06 Jan '03

Why is it that one can't reify top level function declarations? At the moment it only seems that we can reify type declarations. No immediate reason for this seems to spring to mind, but there may be one. Thanks, Sean

1 0

calling haskell from C from haskell
by Arjen Hommersom 03 Jan '03

03 Jan '03

Hello, Is calling haskell from C from haskell possible? This is what i tried (generated with green-card): {-# OPTIONS -#include "Main_stub.h" #-} module Main where import StdDIS foreign export ccall foo :: Int -> Int foo i = i+1 bar :: Int -> IO Int bar arg1 = _casm_ ``do {int arg1;int res1; arg1 = (int)%0; do { res1 = foo(arg1); printf("Result = %%d\n", res1); %r = (int)(res1);} while(0); } while(0);'' arg1 >>= \ res1 -> (return (res1)) main = do i <- bar 1 putStrLn (show i) Compiling it with: ghc -fglasgow-exts -package lang -fvia-C -c Main.hs ghc -o test -package lang Main.o Main_stub.o StdDIS.o results in: $ ./test Result = 2 Segmentation fault compiling it with some variation of startupHaskell() and shutdownHaskell() does not seem to help. Regards, Arjen Hommersom

2 1

RE: Translating seq into Core
by Simon Peyton-Jones 03 Jan '03

03 Jan '03

let b=a in e | -----Original Message----- | From: David Sabel [mailto:dsabel@stud.uni-frankfurt.de] | Sent: 03 January 2003 15:22 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: Translating seq into Core | | Thanks for that answer. I suggested something like that. | Can you explain me, how the Haskell-expression | case a of b -> e (in Haskell, not strict, right?) | ist translated to Core? | | | | | > seq a b = case a of { DEFAULT -> b } | > | > In Core, case is always strict. | > | > | -----Original Message----- | > | From: David Sabel [mailto:dsabel@stud.uni-frankfurt.de] | > | Sent: 03 January 2003 14:11 | > | To: glasgow-haskell-users(a)haskell.org | > | Subject: Translating seq into Core | > | | > | Hallo, | > | | > | my question ist, how the "seq" operator is translated into the | > | GHC-core-language? | > | | > | I had suspected, the core-language has a special strictness-operator, | > but I | > | saw, that this is not the case. | > | | > | | > | David Sabel | > | JWGU Frankfurt | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0