Julian Graham <jool...@gmail.com> 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/>