This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
readtable API
- To: kawa at sourceware dot cygnus dot com
- Subject: readtable API
- From: Felix S Klock II <pnkfelix at MIT dot EDU>
- Date: Wed, 22 Aug 2001 11:39:06 -0400
I've started looking into Kawa's implementation of the readtable API.
I may be able to fix up some things and document/test it (though my
free time is going to take a nose dive after this next week)
I have two questions:
1.) Where are changes usually preferred: in the Java source or in the
Scheme source? Are both up for grabs, and its up to the writer to
decide which place would be better?
2.) How thoroughly are we aiming to support the original Common Lisp
API?
As an example of issues in (2):
http://www.supelec.fr/docs/cltl/clm/node192.html#SECTION002615000000000000000
provides an example use of readtables to extend the syntax of the
language for supporting "xappings, xets, and xectors" There are two
problems Kawa has with this running this example
i.) Kawa's reader treats ']' differently if it is immediately
preceeded by whitespace. Per and I were discussing this
earlier; I'm not sure what the best way to handle it is.
ii.) The command: (set-macro-character #\] (get-macro-character #\) ))
relies on #\) having an appropriate default entry in the
readtable. [Right now Kawa dies horribly w/ NullPtrExn if you
run get-macro-character on a character w/o an entry in the table]
I see (i) as being a bigger problem than (ii). To handle (ii), we'd
just need to document that we don't guarantee any default entries in
the table (which, while inconvenient for the typical Common Lisp
coder, is probably a much better long term specification). Plus
someone could always write a module that loads some appropriate
entries into the readtable to emulate the default for Common Lisp.
For (i), we need to change how the reader handles square brackets. At
least, we'd need to make the readtable have a higher precedence than
the standard kawa reader.
But I think that granting the developer the ability to read
non-schemish syntax (that is, syntax with '[', ']', '{', '}', etc)
would be a great boon for Kawa. At the very least, it would let me
incorporate FX's syntactic sugar for square bracketed expressions.
Per, do you have any guidance for where we should go from here?
-Felix