- Glasgow-haskell-users

RE: GHC Library Documentation
by Simon Marlow 16 Aug '01

16 Aug '01

> The GHC library documentation at > <http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html> > seems to > have a lot missing: > > * certain modules such as MonadError There isn't any documentation for these Monad libraries that I'm aware of. Of course when HaskellDoc is up and running we'll have auto-generated documentation, but until then... > * the 'std' category > * the Prelude 'std' just contains the Prelude and standard libraries, and a bunch of GHC-specific stuff that isn't intended for external consumption. The Prelude and standard libraries are documented in the report and library report respectively (and GHC is pretty ruthless about not exporting extra stuff from these libraries, so the Haskell 98 documentation should be accurate). When we switch over to the new library scheme and get HaskellDoc going, we'll be able to do a much better job here. Cheers, Simon

1 0

GHC Library Documentation
by Ashley Yakeley 16 Aug '01

16 Aug '01

The GHC library documentation at <http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html> seems to have a lot missing: * certain modules such as MonadError * the 'std' category * the Prelude Are there plans to update this, or am I looking in the wrong place? The Library Report sort of covers the 'std' category, though not to the same level of detail, but I can't find anything useful on the Prelude. -- Ashley Yakeley, Seattle WA

1 0

Re: GHCi grumbles (4)
by Alex Ferguson 15 Aug '01

15 Aug '01

George Russell: > If I run GHCi but leave it doing nothing and waiting for input, the process > nevertheless eats CPU time, and is at the moment bringing my RealAudio > relay of Gardeners' Question Time to a halt. Do the GHC Team have > anything to suggest for dealing with this problem? Doubtless due to some _fiendishly_ clever static analysis going on in the background? And let's face it, GQT (and arguably R4 in general) is definitely "background". ;-) Cheers, Alex.

1 0

Re: GHCi grumbles (2)
by Marcin 'Qrczak' Kowalczyk 15 Aug '01

15 Aug '01

Wed, 15 Aug 2001 17:33:02 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > It's hard to do, unless you adopt a policy such as ending the current > input with ';', which doesn't seem terribly attractive. The right way > to do it is for the parser to be incremental and interact with readline, > but I can't see an easy way to do that. And it's not clear when a multi-line expression ends, e.g. case foo of 1 -> xxx 2 -> yyy 3 -> zzz Python uses the convention that an empty line entered interactively ends a multiline statement. Its syntax is different from Haskell in that it can be determined when a statement is multiline from the first line, and that it's not possible to write certain statements in a single line - so for Python it's more important to be able to enter multiline statements. What is a pain in Python: repeating a whole multiline statement (because, say, of an error in the middle made previously) requires bringing each line from history separately. Some Unix shells are different and bring the whole multiline statement from the history, providing a substitute of a full-screen editor, with the main surprises being that Enter executes the statement and up/down arrows typically don't work either. In zsh pressing End at the end of a line, or Home at the beginning, allows to go up and down through lines, and Alt-Enter or Ctrl-V Ctrl-J allow to insert a newline character. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: GHCi grumbles (2)
by Simon Marlow 15 Aug '01

15 Aug '01

> It would also be nice if ghci allowed you to continue onto a > new line. Otherwise > writing long complicated :def scripts is tiresome . . . It's hard to do, unless you adopt a policy such as ending the current input with ';', which doesn't seem terribly attractive. The right way to do it is for the parser to be incremental and interact with readline, but I can't see an easy way to do that. Cheers, Simon

2 1

RE: GHCi grumbles (3)
by Simon Marlow 15 Aug '01

15 Aug '01

> It should be possible to change > (1) the environment returned by System.getEnv > (2) the arguments returned by System.getArgs > (3) System.getProgName > in GHCi (for example, using :set). > > By the way, my partial solution to grumble (1) is > > :def modules (\ modulesStr -> do { let { imports = > Prelude.map (\ modName -> ("import "++(if modName == "+" then > "Prelude" else modName)++"\n")) (Prelude.words modulesStr) ; > imod = "module XYZZY where \n"++(Prelude.concat imports) } ; > Prelude.writeFile "/tmp/XYZZY.hs" imod ; Prelude.return > ":load /tmp/XYZZY.hs" } ) Yes, I experimented with something similar for a while, but did it in an incremental way - I had a :import command which added a line to a temporary module and then re-loaded it. I agree we should have a better way to control scoping at the prompt; there have been one or two good suggestions in the past, but we just haven't got around to implementing anything yet. Cheers, Simon

1 0

GHCi grumbles (4)
by George Russell 15 Aug '01

15 Aug '01

If I run GHCi but leave it doing nothing and waiting for input, the process nevertheless eats CPU time, and is at the moment bringing my RealAudio relay of Gardeners' Question Time to a halt. Do the GHC Team have anything to suggest for dealing with this problem?

1 0

GHCi grumbles (3)
by George Russell 15 Aug '01

15 Aug '01

It should be possible to change (1) the environment returned by System.getEnv (2) the arguments returned by System.getArgs (3) System.getProgName in GHCi (for example, using :set). By the way, my partial solution to grumble (1) is :def modules (\ modulesStr -> do { let { imports = Prelude.map (\ modName -> ("import "++(if modName == "+" then "Prelude" else modName)++"\n")) (Prelude.words modulesStr) ; imod = "module XYZZY where \n"++(Prelude.concat imports) } ; Prelude.writeFile "/tmp/XYZZY.hs" imod ; Prelude.return ":load /tmp/XYZZY.hs" } ) Now if only I had a Haskell function for replacing a Haskell declaration or expression using layout with the appropriate ({/;/}) functions, I could write a :def macro :code (complicated thing split over several lines) :edoc which put everything together and compiled it. Is there a contest for "Worst Abuse of :def"?

1 0

GHCi grumbles (2)
by George Russell 15 Aug '01

15 Aug '01

It would also be nice if ghci allowed you to continue onto a new line. Otherwise writing long complicated :def scripts is tiresome . . .

1 0

GHCi really should allow multiple modules
by George Russell 15 Aug '01

15 Aug '01

GHCi is great. But I really think it should allow you to have multiple modules in scope, since having to qualify either your favorite module or the Prelude all the time is a bore. My complete suggestion is (1) That there be a list of in-scope modules. Names are searched in each module in term, starting at the list head. (2) :module mod1 mod2 ... modn (n>=1) replaces the current list by [mod1,mod2,...,modn] :module mod1 mod2 ... modn + prepends [mod1,mod2,...,modn] to the existing list. :module displays the current list. (3) The prompt show the head of the current list, followed, if the list has more than one element, by a "+" sign. I appreciate that you can load multiple modules by creating a special file containing the relevant import declarations. Indeed, if provoked enough I suppose I might write a :def macro to do this, but it seems rather untidy and can't get at the existing list of modules.

1 0