Folks, There's a long-standing problem in GHCi, namely that when you select a compiled module with ':m M' you can only see the exports of M, and even the exports of the Prelude are hidden. Several people have suggested that this should be improved, and I'm just getting around to implementing something more useful. This message is to gather suggestions on what the user interface should look like in a more general setting, from people who use GHCi more than we do :-) Ok, so in general a 'scope' can be constructed by combining: 1. the full top-level scope from zero or more *interpreted* modules 2. the exports of zero or more modules (interpreted or compiled) 3. any temporary bindings made on the command line I'm assuming name clashes are handled in the normal Haskell 98 way, ie. lazilly, so it might actually make sense to combine the top-level scope of more than one module. Whatever user interface we adopt should provide a way to manipulate these sets. Here's one suggestion: :m M1..Mn set sets 1 & 2 from M1..Mn - use list 1 if Mi is interpreted, otherwise list 2. :m +M adds M to set 1 or 2. :m -M removes M from set 1 or 2. Which leaves one remaining case: adding an interpreted module to set 2. Perhaps this could be ':m *M'. Does anyone have any better suggestions? Cheers, Simon
| Does anyone have any better suggestions? I think any solution that leaves it transparent as to if it is a compiled or an interpreted module is fine. But I have understood that this is hard to achieve... /Koen.
Is there any haskell interpreter done it already? Hugs and hmake support ":also" command. I don't know now exactly it works, but quick test showed than it (sometimes) helps to mix scopes: Hi (hmake/nhc98): ------- begin cut Prelude> :also Maybe [Std module... /usr/local/opt/nhc98/include/nhc98/Prelude.hi] [Std module... /usr/local/opt/nhc98/include/nhc98/Maybe.hi] Maybe> print "a" "a" Maybe> :also IO [Std module... /usr/local/opt/nhc98/include/nhc98/Prelude.hi] [Std module... /usr/local/opt/nhc98/include/nhc98/Maybe.hi] [Std module... /usr/local/opt/nhc98/include/nhc98/IO.hi] IO> listToMaybe [1] Just 1 ------- end cut
A minor suggestion: Let ":m *M" apply to compiled modules as well as interpreted. In other words, ":m +M" requests all top-level entities (accepting only exported ones for compiled modules) while ":m *M" requests only exported entities (whether the module is compiled or interpreted). More generally, though, I dislike allying the "all / exported only" choice with the "add a module to the scope" command; they should be specified independently. In particular, one should be able to make the choice for each of the modules in the ":m M1..Mn" command. (Otherwise, how can one reasonably request a scope consisting of only the exported entities from a single interpreted module?) A question: What is the syntax of the "M1..Mn" form? I like Koen Claessen's suggestion that one be able to request all top-level names from a compiled module. Here's a variant of Simon's proposal that addresses the above concerns: * Let a <mods> be either the name of a module (implying the set of all top-level names in that module) or a square-bracketed, space-separated list of module names (implying the set of names exported from the modules). * Let a <modslist> be a list of <mods>s. Whitespace must separate adjacent <mods>s when neither is in square brackets. * Let the ":module" command take an optional '+' or '-' followed by a <modslist>. '+' indicates additions to the scope; '-' indicates subtractions from the scope; absence of both indicates redefinition of the scope. Square bracketing is suggested for indicating that only exported names are desired, to match the prompt syntax. An alternative for both would be to prefix each such module name by, say, '*'. Examples of these two alternatives: Main[IO]> :module + [Char Monad] Foo Main Foo[IO Char Monad]> or Main *IO> :module + *Char *Monad Foo Main *IO *Char *Monad Foo> I think I prefer the latter. Dean
participants (4)
-
Dean Herington -
Koen Claessen -
Max A.K. -
Simon Marlow