[R6RS] libraries

[dyb at cs.indiana.edu]

> Can you or someone else explain why it has to be this way (or why it  
> is better)?

As I said, we can allow multiple definitions for the same identifier in
the same local scope and try to make sense out of the resulting system,
but it would be a change from past standards and practice, and I think
it would lead to confusion.

> I'm uncomfortable with this inconsistency with top-level  
> syntax definitions.

It's inconsistent with some top levels, but not others.

>     (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)

Foul!  You can't add extra parentheses to my syntax and then complain
about how hard it is to remove them.  The shortcoming is present only
in your version of my syntax.

You can switch between

  (immutable define (f x) ...)

and

  (define (f x) ...)

simply by adding or removing the immutable modifier.  That's part of
the charm.  You can also comment the immutable keyword out if you want.

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

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

The immutable prefix I propose would be built into the macro expander
and work for any macro that expands into one or more definitions, not
just some set of predefined compound definitions like define-type.

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

The majority of editors favor immutable library bindings.  Of the six I
know of who have expressed preferences, only you and I have expressed
a preference for mutable library bindings, and I've said I'm willing
to go that way as well.  It will also be hard to make immutability the
default for libraries unless we do it from the start.

Kent