GHC Poll: scope in GHCi

[Simon Marlow]

Folks,=20

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.

Cheers,
	Simon

> -----Original Message-----
> From: Dean Herington [mailto:heringto@cs.unc.edu]=20
> Sent: 09 January 2002 15:59
> To: Simon Marlow
> Cc: GHC Users Mailing List
> Subject: Re: GHC Poll: scope in GHCi
>=20
>=20
> 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
> interpreted).
>=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?)
>=20
> A question: What is the syntax of the "M1..Mn" form?
>=20
> I like Koen Claessen's suggestion that one be able to request=20
> all top-level
> names from a compiled module.
>=20
> Here's a variant of Simon's proposal that addresses the above=20
> concerns:
>=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).
>=20
>   * Let a <modslist> be a list of <mods>s.  Whitespace must separate
> adjacent <mods>s when neither is in square brackets.
>=20
>   * 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
> scope.
>=20
> 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
> alternatives:
>=20
>     Main[IO]> :module + [Char Monad] Foo
>     Main Foo[IO Char Monad]>
>=20
> or
>=20
>     Main *IO> :module + *Char *Monad Foo
>     Main *IO *Char *Monad Foo>
>=20
> I think I prefer the latter.
>=20
> Dean
>=20
>=20