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]

Re: readtable API



> 3. (set-macro-character #\] (get-macro-character #\) )) is probably
> the wrong thing to do.  It doesn't copy over the bit whether the macro
> is terminating or not.  Use set-syntax-from-char (not implemented)
> instead.

This is an example of what I was referring to earlier when I asked how
throughly we were aiming to support the original Common Lisp API.  If
we're seeking to emulate all of Common Lisp, then we should be able to
run the examples Steele gives in his book without modification, no?

On the other hand, supporting all of Common Lisp's semantics is not a
priority for me.  (For my own testing, I wrote scheme equivalents of
the "xapping" ctor, etc).  So I won't argue further about whether the
code in question was correct or not; I'm happy to make "changes" where
appropriate.

However, in response to your objection to the code:

According to Steele's reference, 

    "get-macro-character returns the function associated with char
     and, as a second value, returns the non-terminating-p flag; it
     returns nil if char does not have macro-character syntax. In each
     case, readtable defaults to the current readtable."

In the readtable.scm source code, it seems that we ARE returning
(invoke entry 'isNonTerminating) as a secondary value.  (Or at least
we would be if we called 'values' instead of 'value').  That is "the
bit whether the macro is terminating or not", no?  Or is
'non-terminating-p' something else for us?

Another question: how strongly do we want to conform to the Common
Lisp interface in readtable.scm ?  "Extra" values aren't as easy to
discard in Scheme as they are in Common Lisp, so perhaps finding a new
interface, or at least adding an alternative readtable lookup
procedure that doesn't involve 'values' would be worthwhile...

-Felix

p.s. I don't suppose I could somehow get the changes to colon/keyword
stuff that I was asking about earlier incorporated into all of this
somehow?  Probably not, since Kawa wants the colon at the end of the
token, so that has to be pretty special syntax-rewriting that is out
of the space of readtables, no?  Oh well.  I suppose I'll just disable
keywords on my own tree as I go. 


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