On Sat, Oct 13, 2012 at 4:56 PM, Marc Feeley
<feeley@x> wrote:
To my dismay I have stumbled across this passage, which I seem to have skipped, or misunderstood, in my previous readings :
"In a library declaration, it is an error to import the same identifier more than once with different bindings, or to redefine or mutate an imported binding with define, define-syntax or set!. However, a REPL should permit these actions."
I have a problem with the restriction on set!. What is the rationale for preventing set! on imported identifiers?
There might be other reasons, but as a spare-time compiler writer, it's extremely valuable for optimization to know that a given named binding from a known named library is never going to change meaning -- ie. when I see "eq?" from the (scheme base) library, I can compile an _expression_ using this identifier very efficiently. If it were possible for eq? to be set! at any time, the compiler would always have to generate a call through a pointer.
This restricts the language and adds complexity (not all variables can be written to). It prevents the definition and use of a "trace" macro, live code patching, etc.
Whether or not a debugger can be written "portably" doesn't mean an implementation cannot provide one.
These are features I expect of a dynamic language and Scheme.
Moreover, it is not clear what is meant by "a REPL should permit these actions". Does "eval" count as "a REPL"? Does it mean that it is only OK if the "set!" was entered at *the* REPL that comes with the system? Or it is always OK on Scheme systems with a REPL? Is it OK if I load from the REPL a file which has a function which does the "set!"? (this would be consistent with the abstraction principle)
If there is a restriction on set!, then I can't implement a REPL with eval using portable code. I can't write a portable "trace" macro. I can't write a portable debugger.
I would like to remove this restriction on set! that makes a builtin REPL appear necessary.
Marc
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports