[R6RS] libraries

[Marc Feeley]

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

>>      (define pi 3.1416)
>>      (immutable pi)
>>      (export pi)
>>
>> instead of
>>
>>      (define-exported-constant pi 3.1416)
>>
>> Can this be done with syntax-case?
>
> Such a thing would be compabible with syntax-case, but I don't think
> offhand that one could write immutable as a macro.  immutable would
> probably have to be built-in.

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.

>   One can write define-immutable as a macro
> with syntax-case, but you're right that this could lead to a  
> proliferation
> of definition forms (like define-type/immutable to make the define- 
> type
> products immutable).
>
> Another possibility is for immutable to be a prefix one can place in
> front of a definition, like (immutable define ---) or
> (immutable define-type ---).  (immutable <defnkwd> <subform> ...)
> would produce the same set of definitions as (<dfnkwd> <subform> ...)
> but all resulting variable bindings would be immutable.
>

I don't like this option because it is harder to read and grep for.   
Moreover, as shown above decoupling the definition and immutability  
declaration allows finer control over the "scope" of mutability.   
Another example:

     ...
     (define pi 3.1416)
     (define-syntax inc (syntax-rules () ((inc) (set! pi (+ pi 1)))))
     (immutable pi)
     (export inc)
     ...

Here pi can be mutated but only by calling the macro inc, which is  
closed in an environment where pi is mutable.  There is no problem in  
exporting the inc macro.  The compiler can easily analyze this code  
and claim that pi is not a constant because an environment where pi  
is mutable is captured by a macro definition (it does not have to  
know that there is a set! in the expanded code (i.e. this analysis is  
conservative).  Had inc never generated a mutation to pi, the user  
could have helped the compiler determine that pi is a constant by  
placing the (immutable pi) declaration before the macro definition.

> Yet another possibility is to control mutability at the library level,
> i.e., have the library form specify whether its exports are mutable
> or not.

True.  What I'm suggesting could also be applied to top-level  
definitions (i.e. mutability is unrelated to libraries).

Marc