Re: (eval '(java.lang.System:nanoTime)) won't work

[Per Bothner <per at bothner dot com>]

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/