[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with rationale & design



On Mon, 21 Jun 2004, Alex Shinn wrote:

> But Scheme48 does acknowledge the importance of being able to load
> modules at the REPL and provides the
> 
>   ,open module
> 
> extension.  Is there a reason this couldn't be made
> 
>   (open module)
> 
> so that the same code could be used in the REPL and compiled?  Not
> attacking here, genuinely curious.

Yes.  In Scheme48's module system, as I've pointed out, makes a clean
separation of module data from the source code it describes.  This is
rather fundamental in the design of the module system.  Notice that
OPEN is a _command_ -- it's a special entity that isn't Scheme code but
that is processed by the command processor.  If it were a regular
Scheme special form (no pun intended), it would embed module data into
Scheme code, thereby breaking the property of the module system.  It
would also terribly confuse the module system, since macros could
expand to it...but the list of structures that are opened determine the
bindings, including syntactic bindings -- i.e. macros --, that are
available, so it would make the whole system needlessly complicated.

> Is there really no point in standardizing any aspect of the REPL,
> something essentially every Scheme provides?  It would at least be
> nice to keep the it as similar to compiled code as possible.

What benefit would be gained from standardizing REPL features?  Most of
each REPL is going to be very different from the next, and chock-full
of completely implementation-specific features _anyways_ -- regardless
of what's standard --; it's not as if we have problems with portability
of REPLs, because if you're using the REPL, you _know_ what Scheme you
are using at the moment : there's no reason to use the least common
denominator and not take considerable advantage of the environment
you're using.

Would you standardize a debugger interface?