[R6RS] libraries

Matthew Flatt mflatt
Tue Dec 6 10:44:33 EST 2005


At Tue, 6 Dec 2005 15:56:53 +0100, "Manuel Serrano" wrote:
> Question 1: Is this a legal library?
> 
> (library <lib-path> <language>
>    ...
>    (define (import x) x)
>    (import 5))

If <lib-path> is "scheme://r6rs", then this is illegal, because
"scheme://r6rs" is defined to export a binding for `import'.

> Question 1b: The SRFI states that "An error is signalled if a macro
> expands to an <impexp-form>."
> 
> Does it implies that import, export, ... are reserved identifiers?

The names `import', `extport', etc. can be used for local bindings, but
they can't be redefined at the module's top level (when the language is
"scheme://r6rs").

> Question 2: From your perspective, is this a legal library?
> 
> (library <lib-path> <language>
>    ...
>    (display x)
>    (define x 5)

Syntactically, yes. I think of it as a run-tmie error, because `x'
doesn't have a value when the `display' is evaluated. Probably we need
to pin this down better.

> Question 3: From your perspective, is this a legal library?
> 
> (library <lib-path> <language>
>    ...
>    (display x)
>    (define (x) 5)

Same as above, to me.

> Remark 1: In general I'm wondering if it is reasonable to be so vague 
> on the semantics of the body execution. If we are trying to get
> portability I think that we will have a problem here.

I agree.

> Question 4: Unless I have missed something, in the library SRFI, you
> don't specify that exported bindings are immutable. As far as I remember
> we have all agreed on that point. So, is it on purpose that you don't 
> mention it?

I thought that we settled on exported bindings as mutable, and that
it's one of the motivations for indirect exports.

> Remark 2: I don't understand why the library SRFI should specify 
> that macro-expansion obeys lexical scope. For me, it is one step too far. 
> The library SRFI could be more neutral on this topic. Speaking for myself,
> I don't sure that I agree with this rule.

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.

> Remark 3:  It is not clear to me (unless I have missed that too) that the
> library semantics clearly bans cyclic import dependencies. Is it on purpose? 
> (I don't remember if we had a agreement on cyclic vs acyclic imports.)

It should clearly ban cyclic dependencies. I'll work on that.

Matthew



More information about the R6RS mailing list