[R6RS] libraries

Thu Dec 8 11:57:54 EST 2005

At Wed, 7 Dec 2005 10:06:28 +0100, "Manuel Serrano" wrote:
> > > Are you using a unique environment for 
> > > macros and variables? In other words, do you mean that it is an
> > > error to define a macro and a variable with the same name?
> > 
> > Yes. It seems that we simply disagree on this point.
> Yes. I'm afraid that we disagree. The problem, I think, is that the current
> design relies on this merged namespace.

I agree that the current design relies on a single namespace for bindings.

> Without it, how do you handle
> intuitively:
> 
>   <body> = <impexp-form>* <comdef-form>*
> 
> You could imagine a kind of virus such as:
> 
> (library <lpath> <lang> 
>   (export export)
> 
>   (define (export . l) <do something nasty>))
> 
> To me, the solution to this problem is not to enforce a unique namespace
> but to give more structure to library. For instance, I think that an 
> alternative design could be:
> 
> (library <lpath> <lang> (<impexp-form>*) <body>)

I'm not opposed to this in principle, and I see how it solves the above
problem.

But I don't understand what you have in mind more generally. What if a
library imports from from others, A and B, where A exports a function
`foo' and B exports a macro `foo'. When `foo' is used, which binding
applies?

> > > > I think the `library' form has to work well with macros, or it won't be
> > > > a useful standard (and "work well" to me means "obeys lexical scope").
> > > > If there's disagreement on this point, we should certainly discuss it
> > > > further.
> > > I imagine that I will be pretty alone on this side but no, I don't
> > > think that I want to enforce macros to use lexical scoping. I think
> > > that, at least, we should not specify this in the library specification. In
> > > particular, I think that we can adopt SYNTAX-CASE. We can specify that
> > > macros defined with SYNTAX-CASE are hygienic but I don't think that we
> > > should specify that a Scheme that uses traditional Lisp macros cannot
> > > be R6Rs because of the specification of the LIBRARY form. 
> > 
> > If an implementation supports defmacro, then certainly such macros
> > wouldn't be required to obey lexical scope. Where the SRFI says
> > "macros", I had in mind "macros defined using standard mechanisms",
> > which I expect to be `syntax-rules' and `syntax-case'. In any case, I
> > think the library and macro standard parts of the will have to
> > reference each other.
> May be but do you think that dropping the paragraph above would really
> change something for the comprehension and description of the libraries.
> 
>  "Macro expansion obeys lexical scope in the sense that if a macro
>  expansion introduces a identifier that is bound in the context of the
>  macro definition, it refers to the binding in the environment of the
>  macro-definition library, not in the environment of the expansion."

In the present situation, where there's not yet a syntax SRFI, I think
the paragraph helps the SRFI audience understand the editors' plans for
R6RS (i.e., that macros and libraries will play together). Otherwise,
it doesn't say much at all.

> I have another remark that I have already made but I would like everybody's
> opinion. This remark is about interpreter vs compiler. I imagine that
> we are going to support the function EVAL.

Actually, I would like to remove `eval' and `load' from
"scheme://r6rs". I think it belongs with the definition of a top level
(if we end up with one).

Matthew