On Sat, Oct 13, 2012 at 4:56 PM, Marc Feeley <[email protected]>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 > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports >
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
