[R6RS] libraries

[dyb at cs.indiana.edu]

> 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.

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

I don't see why.

> 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,
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.

Kent