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
[email protected] http://per.bothner.com/
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
