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