(eval '(java.lang.System:nanoTime)) won't work
Per Bothner
per@bothner.com
Wed Jun 12 07:27:00 GMT 2013
On 06/09/2013 12:04 AM, Morven Sun wrote:
> the error message is: unbound location java.lang.System:nanoTime
>
> but (java.lang.System:nanoTime) is just fine
>
> so what's wrong? I'm new to kawa but have a little experience of
> scheme and java.
FWIW - I checked in a fix to make this work.
Background:
In general EXPR:NAME is a colon-expression. The Scheme
reader turns this into the list ($lookup$ EXPR (quote NAME)),
and then various part of Kawa handle these forms. However,
Kawa has some special handing for when EXPR is an identifier,
as in PREFIX:NAME. If PREFIX is bound to a namespace, then
the result is a compound name. Specifically, when quoted
as in 'PREFIX:NAME the result is a compound symbol.
http://www.gnu.org/software/kawa/Namespaces.html
The problem is that standard Scheme does not treat colon
as a special character - it can be a regular character
in an identifier. So a symbol A:B is legal - and is a
plain identifier (symbol). So Kawa has some hacks to deal
with code written with this assumption.
Before, when you quote a compound symbol A:B where A is
*not* bound to a namespace, Kawa would convert it to
|A:B| - i.e. a 3-character symbol for "A:B". The problem
is when you try to eval this symbol it doesn't work.
Now Kawa already had a concept of a symbol that has a
prefix but "unknown namespace uri". So I changed the
handling of 'A:B to return one of those. To make eval
work I also had to change the rewrite phase to
recognize a "symbol with unknown namespace" just as it
already did special handling for ($lookup$ A (quote B)).
An interesting follow-up "fix" is to also change the
Scheme reader, such that PREFIX:NAME returns a "symbol
with unknown namespace". This would be a special case
- the general EXPR:NAME would still be read as
($lookup$ EXPR (quote NAME)).
I think this would make symbol-handling a bit cleaner.
However, there are of course complications. One is we
need to handle names with multiple colons: A:B:C.
Also tricky is handling hygienic macro expansion: If
a macro template contains A:B we need to handle the case
that either A or B is a macro pattern name. OTOH some
other things would be simplified.
--
--Per Bothner
per@bothner.com http://per.bothner.com/
More information about the Kawa
mailing list