Le 2012-11-14 à 5:18 AM, Helmut Eller <[email protected]> a écrit :
> On Wed, Nov 14 2012, Alex Shinn wrote: > >> Then why can you say that a REPL "should" support redefinition? >> (Without defining what redefinition means.) >> >> This refers to redefining variables and syntax in general. >> >> For the specific case of redefining record types we could >> add a note that existing instances may or may not be >> mapped to the new type according to some unspecified >> semantics, but I'm not sure if such a note adds anything. > > Just figured out that neither include nor load can be used to > define/redefine libraries. So libraries are immutable and there is no > portable way to "add" new libraries, right? > > Helmut Let me say that I find it contrary to the spririt of Scheme to prevent redefinition and assignment of exported variables. It is something Schemers do all the time. Of course there is the usual argument that this restriction is in place to allow efficient compilation, allowing, among other things, inlining of exported functions. This argument seems to ignore the fact that good JIT compilers (such as V8 for JavaScript) are perfectly able to speculatively inline functions bound to mutable variables. It takes a cleverer compiler, but it does not prevent function inlining. So it seems that preventing this useful feature (function redefinition at the REPL, or by a "load" or "eval") is simply there to make the Scheme implementer's life easier. That's the wrong thing to optimize... if implementation difficulty is a concern we will soon get rid of continuations, the REPL, and maybe closures and garbage collection. I find this design choice unacceptable and a show stopper for me. Marc _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
