Re: [Scheme-reports] REPL

[Per Bothner <per@x>]

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