[R6RS] libraries

[Marc Feeley]

Concerning mutability, we should not forget that Scheme has had a  
long history of being liberal about mutation, even "function names"  
are viewed as mutable variables.  Although this causes immense  
difficulty for the optimizer there are some good things to be said  
about it (for tracing, debugging, overloading, etc).  Allowing  
mutation is a direct application of our mantra:

      Scheme demonstrates that a very small number of rules for  
forming expressions,
      with no restrictions on how they are composed, suffice to form  
a practical and
      efficient programming language that is flexible enough to  
support most of the
      major programming paradigms in use today.

I'm not saying that immutability is not a useful concept, especially  
for software engineering, but that having mutable variables is less  
restrictive, and thus more expressive.  Moreover, it seems that we  
have several possible meanings for immutability:

1. not mutable at all
2. not mutable from the client side, but mutable in the library
3. not mutable from the client side, but mutable in the library and a  
derived
    library (sort of like "protected" in Java)
4. ...

We should not force a particular meaning on the user.  What I would  
prefer is to decouple mutability from the librairies.  As far as I  
can tell we can implement immutable bindings using syntax-case's  
identifier syntax.  Isn't that good enough?

The ideal form would decouple the definition of a variable and the  
declaration that it is immutable (to avoid a slew of slightly  
different define forms, e.g. "define", "define-constant", "define- 
exported", "define-exported-constant", ...).  Something like

     (define pi 3.1416)
     (immutable pi)
     (export pi)

instead of

     (define-exported-constant pi 3.1416)

Can this be done with syntax-case?

Decoupling the definition and mutability declaration would give a  
fine degree of control over mutability, for example to allow a  
"window" where mutation is possible:

     (define pi 3.1416)
     (define (inc) (set! pi (+ pi 1)) pi)
     (immutable pi inc) ; pi and inc can't appear as the target of a  
set! from here on

Marc

On 12-Dec-05, at 3:12 AM, Michael Sperber wrote:

>
> dyb at cs.indiana.edu writes:
>
>> So, while I think I can probably implement your modified semantics  
>> (both
>> set! and lhs id must originate in the exporting module), it's only  
>> one
>> of several possible interpretations of "settable only by the  
>> exporting
>> module", and I believe it will lead to confusion.  Your semantics
>> also falls short of supporting program analysis in the way that true
>> external immutability would, negating one of the potential benefits
>> of immutability.
>>
>> I'm happy to compromise on the mutability issue and make module  
>> exports
>> immutable if all exports (direct or indirect) are totally immutable,
>> so that we avoid confusion and support program analysis.  Of course,
>> you may not need me to be happy if I end up in the minority.
>
> I believe two things got slightly confused here: You asked me what I
> meant when I used the term "immutability," but that doesn't mean it's
> the only thing I'd agree to.  Previously, I had thought the term was
> clear, but you reminded me that it's in fact highly ambiguous, and I'm
> happy the issue got illuminated---thanks for that!
>
> Sure, the kind of immutability I described disables *some* program
> analysis, but it sure doesn't disable *all* program analysis that
> allows optimization.  There's a whole spectrum here, leading all the
> way up to SML, where all bindings are immutable, so it doesn't seem
> clear that program analysis should trump us to any particular place in
> the middle of that spectrum.
>
> To be clear: Making all exports immutable would also be agreeable to
> me.  (Also, I'd *like* you to be happier than you are, even if I don't
> *need* you to be :-) )
>
> Rationale-wise, remember that we're discussing a library standard
> rather than a module system.  While I'd agree with your argument in
> favor of separating out immutability from the module system the
> context of a Chez-style module system (...), I don't agree with it in
> this context, where we're prescribing policy just as much as we're
> providing means for abstraction, and possibly more.
>
> -- 
> Cheers =8-} Mike
> Friede, V?lkerverst?ndigung und ?berhaupt blabla
> _______________________________________________
> R6RS mailing list
> R6RS at iro.umontreal.ca
> http://mailman.iro.umontreal.ca/mailman/listinfo/r6rs