This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: New Kawa features - and incompatibilities
Jim White wrote:
Per Bothner wrote:
The other big change is that the "path expressions" discussed in
http://www.gnu.org/software/kawa/PathExpressions.html
now use colon rather than backslash.
...
This is where old code might break. The problem (which existed
before but is now likely to be worse) is that non-Kawa-specific
Scheme code uses colon as a regular symbol constituent. So
you might a symbol named
format:symbol-case-conv
as well as a function named format.
Do you attempt a lookup of the whole symbol before parsing it for the
colon? If so, I think most old and non-Kawa-specific code is reasonably
supported.
Yes. However, the problem is compile-time lookup vs run-time lookup.
We need to decide whether to use the whole symbol at compile-time,
when we don't what symbols are available at run-time.
Consider the compound
A:B
If A is a lexical variable, we need to resolve it at compile-time.
So what happens at compile-time is:
If A:B has a compile-time or lexical binding, use A:B as a symbol.
Otherwise, if A has a compile-time or lexical binding, compile it
as if it was ($lookup$ A 'B).
Otherwise, do a run-time lookup of |A:B|.
There are some corner cases that aren't quite right. For example,
if you type this into the REPL:
(begin (set! A '(3 4)) A:car)
it looks for |A:car| rather than the car of |A|, because |A| isn't
defined when we compile A:car. Ideally, we should look for |A|
when the runtime lookup of |A:car| fails. That doesn't seem
very difficult, but I don't think I'll worry about it for the
initial check-in.
--
--Per Bothner
per@bothner.com http://per.bothner.com/