New Kawa features - and incompatibilities

[Per Bothner]

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/