Re: [Scheme-reports] set! and imported identifiers

[Alex Shinn <alexshinn@x>]

On Sun, Oct 14, 2012 at 5:56 AM, Marc Feeley <feeley@x> 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?  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.  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.

The builtin REPL is defined in terms of (interaction-environment),
which does allow set! and define.  Using this you could provide
your own REPL, so long as it used that environment.

I'm reviewing the ballots and discussions, but I believe the spirit
of one change was to make the result of (environment) mutable as well.

Of course you can't portably trace a binding or make live code
patches - these are not aspects of finished code that you want
to publish, but part of the development process.  Every Scheme
will have strengths and weaknesses in their runtime environment.
When the standard says something is an error, it's fully expected
that some Scheme will come in and provide some semantics
they consider useful in that case.

I will follow up on the mutability of (environment) but have to run now.

-- 
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports