Re: [Scheme-reports] REPL Helmut Eller (14 Nov 2012 08:51 UTC)
Re: [Scheme-reports] REPL Alex Shinn (14 Nov 2012 09:07 UTC)
Re: [Scheme-reports] REPL Helmut Eller (14 Nov 2012 09:13 UTC)
Re: [Scheme-reports] REPL Alex Shinn (14 Nov 2012 09:26 UTC)
Re: [Scheme-reports] REPL Helmut Eller (14 Nov 2012 10:22 UTC)
Re: [Scheme-reports] REPL Marc Feeley (14 Nov 2012 21:06 UTC)
Re: [Scheme-reports] REPL John Cowan (14 Nov 2012 21:26 UTC)
Re: [Scheme-reports] REPL Marc Feeley (14 Nov 2012 22:05 UTC)
Re: [Scheme-reports] REPL Alex Shinn (14 Nov 2012 23:46 UTC)
[Scheme-reports] equal? Alan Watson (15 Nov 2012 00:40 UTC)
Re: [Scheme-reports] equal? Jim Rees (15 Nov 2012 02:36 UTC)
Re: [Scheme-reports] equal? John Cowan (15 Nov 2012 16:26 UTC)
Re: [Scheme-reports] equal? Alan Watson (15 Nov 2012 16:35 UTC)
Re: equal? Arthur A. Gleckler (17 Nov 2012 20:32 UTC)
Re: [Scheme-reports] REPL John Cowan (15 Nov 2012 16:23 UTC)
Re: [Scheme-reports] REPL Aaron W. Hsu (15 Nov 2012 23:47 UTC)
Re: [Scheme-reports] REPL Shiro Kawai (16 Nov 2012 01:16 UTC)
Re: [Scheme-reports] REPL Per Bothner (14 Nov 2012 21:37 UTC)
Re: [Scheme-reports] REPL Marc Feeley (14 Nov 2012 21:49 UTC)
Re: [Scheme-reports] REPL Andy Wingo (04 Jan 2013 13:02 UTC)
Re: [Scheme-reports] REPL John Cowan (04 Jan 2013 15:42 UTC)
Re: [Scheme-reports] REPL Alaric Snell-Pym (04 Jan 2013 16:30 UTC)
Re: [Scheme-reports] REPL Helmut Eller (15 Nov 2012 07:44 UTC)
Re: [Scheme-reports] REPL John Cowan (15 Nov 2012 16:04 UTC)
Re: [Scheme-reports] REPL Per Bothner (15 Nov 2012 16:17 UTC)

Re: [Scheme-reports] REPL Marc Feeley 14 Nov 2012 22:00 UTC

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