Scheme language standardization process
On 11/14/2012 01:01 PM, Marc Feeley wrote: > Let me say that I find it contrary to the spririt of Scheme to prevent redefinition and assignment of exported variables. Let me say that regardless of the "spirit of Scheme", I think disallowing redefinition / re-assignment is a Good Thing. At least as a default: It might be reasonable to allow re-assignment for variable that have been explicitly declared to allow that, though I don't see a major use case for it. Also, an implementation might allow a "debug mode" that can allow exported variables to be re-assigned, but I don't think it should be alloweded in normal use. Two alternative to consider (perhaps for WC2): * Kawa has a define-variable form which is used to explicitly mark dynamic variables. I.e. these force dynamic run-time lookup, without inlining. This is also a convenient way to turn off compile-time undefined-variable warnings/errors, for compilers that offer that. * A mechanism to define "properties": Associate a variable with a pair of a getter and a setter function. This allows generate read or write hooks (useful for debugging and many other purposes). One might allow exporting of a getter/setter pair, which can be used as a variable. (This is just an idea - I haven't actually tried to see how this might work for Scheme libraries.) > 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. That's an important reason, but equally important is that it makes programs more maintainable and understandable *to humans*. It makes it easier to debug a program if you can easily find all the places that assign to a variable. This restriction is also helpful if you care about security. > 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. Well, there are good arguments for getting rid of traditional general continuations - and not just implementation difficulty. It does seem clear that something *like* continuations - or co-routines - are valuable. -- --Per Bothner per@x http://per.bothner.com/ _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports