Le 2012-11-14 à 4:22 PM, John Cowan <cowan@mercury.ccil.org> a écrit :

> Marc Feeley scripsit:
>
>> 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.
>
> Please note that R7RS, unlike R6RS, does not outright forbid redefinition
> of imported (as opposed to exported) variables; it simply excludes such
> actions from the purview of the standard.

R7RS defines mutation of imported variables as "an error".  This looks like a restriction to me and goes against the Scheme mantra "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions...".

Scheme has had mutation since the beginning.  All variables are mutable.  No exceptions.  Now R7RS is adding a restriction on variables (mutation in not allowed on imported variables).  This is incoherent with the Scheme mantra.

>> I find this design choice unacceptable and a show stopper for me.
>
> I hope the above relieves your concerns, which I wish you had mentioned
> sooner.

Well I did mention this in the past to this list (last time was october 13, message copied below).

Marc

Début du message réexpédié :

> De : Marc Feeley <feeley@IRO.UMontreal.CA>
> Objet : set! and imported identifiers
> Date : 13 October, 2012 4:56:53 PM EDT
> À : scheme-reports <scheme-reports@scheme-reports.org>
>
> 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.
>
> Marc

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