Re: Portable Syntax Case

[Adam Warner <lists at consulting dot net dot nz>]

On Mon, 2004-04-19 at 19:10, Per Bothner wrote:
> > I had to fix Kawa's potential number reader because it was mistaking
> > symbols prefixed with an underscore and followed by number characters as
> > "not a valid number" instead of symbols:
> 
> The existing code follow the Common Lisp "potential number" syntax,
> which does exclude some valid Scheme identifiers.  I think the
> following is a slightly more conservative patch:

I'm impressed by your knowledge of ANSI Common Lisp potential numbers.
It didn't register at first why you singled out an underscore in the
code. Per is talking about this part of the ANSI Common Lisp
specification:
<http://www.lispworks.com/reference/HyperSpec/Body/02_caa.htm>

It is my understanding that an implementation is free to interpret
potential numbers that turn out to be non-numbers as symbols. In other
words the chance that a potential number presently interpreted as a
symbol could be interpreted as a number some time in the future is a
risk that can be left to users.

I believe this interpretation is reinforced by the examples in 2.3.1.1.2
where it states "As examples, the tokens in the next figure are
potential numbers, but they are not actually numbers, and so are
reserved tokens; a conforming implementation is permitted, but not
required, to define their meaning." Every Common Lisp implementation I
have tested (CLISP, CMUCL, SBCL and GCL) presently defines the meaning
of the potential number _123 as a symbol.

We can even telnet into prompt.franz.com and test out Allegro:
CL-USER(1): (symbolp '_123)
T

Thanks for the patch.

> > With this fixed and Kawa recompiled I have now struck this error when
> > attempting to load psyntax.pp:
> > 
> > java.lang.VerifyError: (class: atInteractiveLevel$frame, method:
> > lambda186genSyntaxCase669 signature:
> > (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) Incompatible type for getting or setting field
> >         at atInteractiveLevel.apply(psyntax.pp:6)
> 
> I have duplicated this.  It looks like a bug in using the wrong
> "closure object":

...

> The closure handling code is unfortunately some of the more
> complicated and fragile parts of Kawa, because it supports
> a number of different strategies.

I suspected this could be a bug in Kawa's implementation. Thank you for
the analysis. I'd like to know how you obtained the disassembly.

> I've tried to figure out psyntax.scm in the past, and given
> up.  I don't like the strategy of trying to compile psyntax.pp
> because it would be hard to integrate that cleanly into Kawa.
> Instead, I'd rather "reimplement" the concepts of psyntax.scm
> using java code.  This would be a lot more efficient and more
> integrated, and would be allow for easier bootstrapping.
> However, I find the algorithm difficult to understand and
> unintuitive, and I've never put in the time to try to really
> understand it.
> 
> I also find syntax-case very poorly specified.  All I can find
> are examples of its use, but no real semantic specification,
> formal or informsl.  For example, something as obvious as
> what identifiers are valid in macro transformers isn't even
> mentioned anywhere I've seen.  This has reduced my incentive
> to try to understand it and get it working ...

It's my opinion that because this is incompletely specified and baroque
that you shouldn't attempt to reimplement psyntax.scm in Java. It's
better freeriding upon the canonical implementation while a
specification stabilises. It's thousands of lines of complicated code
and the only way to be 100% compatible will be to use their code.

> On the other hand, it *would* be nice to have syntax-case
> working fully.  (A small subset of syntax-case does work.)

Not enough to be "portable" unfortunately. Kawa fails on the first
example (and2) in
<ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/iucstr356.ps.gz>
(since the `syntax' symbol is unsupported).

As it appears the error message is due to the robustness of Kawa's
closure handling fixing this would of course be nice. I appreciate you
are very likely to have more pressing objectives.

Many thanks for your reply.

Regards,
Adam