This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: incompatible change for keyword literals in Kawa Scheme
- From: Per Bothner <per at bothner dot com>
- To: Helmut Eller <eller dot helmut at gmail dot com>
- Cc: kawa at sources dot redhat dot com
- Date: Sun, 08 Mar 2009 11:09:53 -0700
- Subject: Re: incompatible change for keyword literals in Kawa Scheme
- References: <49B2F36C.6080601@bothner.com> <m2ab7wjp1d.fsf@gmail.com>
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/