Re: r6rs libraries, round three

[Julian Graham <joolean@gmail.com>]

Hi Andreas,


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

You're right, it doesn't -- at least, it's not required that an
implementation prevent you from referencing an identifier at a phase
other than the one it was imported for.  I was reading that part of
the spec in terms of non-macro definitions, but, come to think of it,
it's got to apply to macros as well.  So importing everything at once
sounds like it'll work just fine.


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

I was tracking SRFI-103 for a while back when it was (I think)
SRFI-100.  I'm interested to see how it pans out, but I'm not sure I
agree with its rationale -- it seems mostly useful for implementations
that don't currently have their own library search mechanism.  The bit
about "distributing and using library files in a portable way" seems a
bit hand-wavy to me.


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

Yes, it's a bit thorny.  We discussed the limitations in a thread [1]
a while back.  The implementation I did reflects the outcome of that
thread, which was that the version of a library that gets loaded is a
function of the import statements, the available libraries, and the
set of already-loaded libraries -- which means that it's not a fully
predictable process from the point of view of library authors, but
that in practice, collisions aren't likely for a variety of reasons.


Regards,
Julian

[1] - http://www.mail-archive.com/guile-devel@gnu.org/msg03673.html