Re: r6rs libraries, round three

[Andreas Rottmann]

Julian Graham <address@hidden> writes:

> I probably should have said "rough prototype" instead of "working
> prototype" -- the actual macro that transforms library definitions
> into module definitions is kind of gross and uses datum->syntax a fair
> amount where it probably doesn't need to / shouldn't.  I'm no syncase
> wizard.  But I'm pretty sure it works for conventional libraries that
> import and export macros and regular bindings.  (What I worry about
> are some of the hairier use cases of the whole "phased import"
> mechanism -- like a binding that's imported at `meta' level 2 or
> higher sharing a name with definition imported for use at runtime.)
>
IIRC, R6RS doesn't /require/ that implementations are able to
differentiate bindings from different phases -- e.g. Ikarus essentially
ignores phase specifications (implicit phasing -- there were some
discussions about that on ikarus-users, which I can't find ATM, but [0]
should sum the issue up nicely).

[0] http://www.phyast.pitt.edu/~micheles/scheme/scheme21.html

> What I'm mostly interested in is whether you guys think the version
> and export patches are worth merging in some form or another -- my
> assumption has been these are features we actually want for Guile's
> module system.
>
Are you aware of SRFI-103? It got recently revised to leave out
versions; not supporting them is an option, I guess. Quoting from R6RS:

,----
| When more than one library is identified by a library reference, the
| choice of libraries is determined in some implementation-dependent
| manner.
| 
| To avoid problems such as incompatible types and replicated state,
| implementations should prohibit the two libraries whose library names
| consist of the same sequence of identifiers but whose versions do not
| match to co-exist in the same program.
`----

This makes me wonder if versions can be used (or rather be relied on)
sensibly in portable libraries at all...

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>