[R6RS] libraries

[Marc Feeley]

On 13-Dec-05, at 3:05 PM, dyb at cs.indiana.edu wrote:

>> You're the expert on this, so I'll take your word for it.  Could this
>> be seen as a weakness of syntax-case, and perhaps an extension could
>> be designed?  What I would like is
>>
>>     (define pi 3.1416)
>>     (define (inc) (set! pi (+ pi 1)) pi)
>>     (immutable pi)
>>
>> to expand into
>>
>>     (define pi 3.1416)
>>     (define (inc) (set! pi (+ pi 1)) pi)
>>     (define-syntax-non-recursive pi (identifier-syntax pi))
>>
>> such that the pi inside the (identifier-syntax pi) refers to the
>> variable pi defined before the define-syntax-non-recursive.  After
>> the (define-syntax-non-recursive pi ...), the identifier pi cannot be
>> used in a set! and exporting pi will export the macro, so it can't be
>> assigned to in a client library.
>
> This kind of extension would probably be doable, but R5RS and current
> implementations of syntax-case don't allow multiple definitions of the
> same identifier in the same (local) scope, and this is also a  
> requirement
> for the body of a library in the current library draft.
>
> It's no problem to make this work already at top-level.
>

Can you or someone else explain why it has to be this way (or why it  
is better)?  I'm uncomfortable with this inconsistency with top-level  
syntax definitions.

>> I don't like this option because it is harder to read and grep for.
>
> I don't see why.

I usually grep for "(define " to get definitions.  Also the form

    (immutable define (f x) ...)

feels awkward, and does not look like a definition.  Yes it's a  
matter of taste and exposure to this style.  An extra pair of  
parentheses would please me more:

    (immutable (define (f x) ...))

Another irritant is that this fuses the immutability declaration and  
the definition.  It is hard for example to switch from an immutable  
to mutable definition (need to remove the "(immutable" and closing  
parenthesis, and reindent).  With a decoupled declaration you simply  
remove a line or add a semicolon:

    (define (f x) ...)
    ;(immutable f)

>
>> Moreover, as shown above decoupling the definition and immutability
>> declaration allows finer control over the "scope" of mutability.
>
> Yes, but you lose the ability to mark whole groups of bindings,

This is just a convenience.  You could list them all.  Anyway, this  
convenience can also be built in to the immutable form which would  
iterate over the bindings of the type, just like the export form has  
to.  Perhaps that is your point?  That it is hard to write the  
immutable form as a macro.

> including those implicitly generated by, say, define-type immutable
> with one keyword.  With the immutable prefix, one can even make all of
> the bindings of a library immutable by writing
>
>   (immutable begin <defn> ...)
>
> since begin is itself a definition.  It all depends on what you want.
>
> But we're engaging in language design research here.  If we're going
> to have some built-in mechanism for immutability in R6RS, as opposed
> to something that the user does in an ad-hoc manner with identifier
> macros, it is probably best to tie it to libraries, since we already
> have experience with that.

Then, as I said previously, it seems more consistent with the Scheme  
design approach to have mutable bindings everywhere.  We can later  
(R7RS) add a mechanism to specify that a binding is immutable (be it  
an immutable form or an export option or something else).

Marc