This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

readtable API




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]