This page is part of the web mail archives of SRFI 55 from before July 7th, 2015. The new archives for SRFI 55 contain all messages, not just those from before July 7th, 2015.
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?