This is the mail archive of the kawa@sourceware.org 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]
Other format: [Raw text]

Re: incompatible change for keyword literals in Kawa Scheme


On 03/08/2009 03:18 AM, Helmut Eller wrote:
* Per Bothner [2009-03-07 23:21+0100] writes:

If this is a problem for anyone, we could put in a hack to
make colon-follow-by-digit be the start of a symbol, while
colon-followed-by-non-digit be the start of a keyword.
However, I'd prefer to not do that.

Is there a readtable that implements only standard r5rs or r6rs syntax, without infix and postfix stuff, and that remains stable?

If wouldn't be difficult to add, I think, though you'd lose some of Kawa's features, such as colon notation and keywords - at least the convenient syntax for those features.

It's probably possible to have better compatibility while still
offering the Kawa syntax, by resolving the extensions at expand-time
rather than at read-time.  This is how quantities like 3cm are handled.
Kawa already has some hacks to deal with non-Kawa-code that contains
symbols with colons.

What complicates this is:
(1) Need to handle hygienic macros and "syntax objects".
(2) Need to preserve actual input syntax - i.e. we need to
distinguish |foo:bar| from |foo|:|bar|.  In this model foo:
could be a symbol |foo:| that has a pre-defined binding of the
corresponding Keyword, but it could be rebound to some other
value.  However, |foo:| might disable the keyword lookup, so
|foo:| would be an identifier. A quoted 'foo: would evaluate
to the symbol |foo:|.  Things like this could be handled by a
mechanism to get the "raw source token" from a syntax object,
but it might be getting close to the overly-clever side.

I think this is doable and worthwhile, but it's not a quick hack.

There are other non-lexing incompatibilities.  For example, Kawa will
assume that various top-level and standard names doesn't get
redefined, so it can inline them at compile-time.  This will be
easier in a standard-conforming way if using R6RS libraries
(which aren't supported yet).
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


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