GHC Poll: scope in GHCi
Wed, 23 Jan 2002 11:40:38 -0000
Dean Herington suggested another possible syntax for the :module
command. To paraphrase, the new syntax would be:
:m [+|-] [*]M1 ... [*]Mn (n >=3D 0)
Using the convention that  indicates an optional syntactic element,
'|' indicates choice, and M1 ... Mn are module names.
- with no +/-, the command sets the scope
- with +, the indicated modules are added to the scope
- with -, the indicated modules are removed from the scope
- 'M' means include the full top-level scope of module M
- '*M' means include just the exports of module M
Currently the non-* form isn't supported for compiled modules, and
attempting to set an unsupported scope results in an error.
I think this is simpler than the original suggestion, although it makes
some cases erroneous where the previous form would "do the right thing".
Eg. Now you have to say ':m + *IO' to import IO, whereas previously you
could just say ':m +IO'. I think I'd probably ":def :import (return .
(":m + *" ++))".
On the other hand, the new form separates what is really just an
implementation restriction (that we can't load the top-level scope of a
compiled module) from the user interface, which is a good thing. At
some point we might lift the restriction, which we could do without
changing the meaning of the :m command.
Unless anyone has any more suggestions or objections, I'm inclined to go
with this syntax.
> -----Original Message-----
> From: Dean Herington [mailto:email@example.com]=20
> Sent: 09 January 2002 15:59
> To: Simon Marlow
> Cc: GHC Users Mailing List
> Subject: Re: GHC Poll: scope in GHCi
> 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=20
> *M" requests
> only exported entities (whether the module is compiled or=20
> More generally, though, I dislike allying the "all / exported=20
> 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=20
> choice for
> each of the modules in the ":m M1..Mn" command. (Otherwise,=20
> how can one
> reasonably request a scope consisting of only the exported=20
> 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=20
> all top-level
> names from a compiled module.
> Here's a variant of Simon's proposal that addresses the above=20
> * Let a <mods> be either the name of a module (implying the=20
> set of all
> top-level names in that module) or a square-bracketed,=20
> 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 '-'=20
> followed by a
> <modslist>. '+' indicates additions to the scope; '-' indicates
> subtractions from the scope; absence of both indicates=20
> redefinition of the
> Square bracketing is suggested for indicating that only=20
> exported names are
> desired, to match the prompt syntax. An alternative for both=20
> would be to
> prefix each such module name by, say, '*'. Examples of these two
> Main[IO]> :module + [Char Monad] Foo
> Main Foo[IO Char Monad]>
> Main *IO> :module + *Char *Monad Foo
> Main *IO *Char *Monad Foo>
> I think I prefer the latter.