[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI-10 intent: new notation and _some_ guidelines of its interpretation
Date: Fri, 8 Oct 1999 19:16:03 GMT
You said it very well. SRFI-10'th intent is indeed to extend the
grammar for external representations; SRFI-10 indeed does not aim to
specify all the details (where tag-symbols are stored, how they come
into being, etc). SRFI-10 however resolves to provide #,()
interpretation guidelines -- an interface so to speak.
It appears that comparison with the Reader Algorithm of CL illustrates
very well what the latter phrase means:
[... quote elided ...]
The quote above defines the interface of a reader macro function,
and specifies what it can or cannot do. SRFI-10 aims to do the same
with regards to reader-constructors.
The above could be reduced to `yes, but no'. You agree with me that
SRFI-10 is proposing a convention for future SRFI's, and then go on
about `reader-constructors' and implementing some form of read-time
evaluation. If what I said was correct there is no need to talk about
implementation at all. Future SRFI's that contain concrete proposal
for extensions can talk about implementations. You have nothing to
implement. Consider the first of your implementation strategies:
- offer a _fixed_ set of specific symbolic tags and
associated constructor procedures;
Every Scheme implementation already has this: it implements SRFI-10
with an empty set of symbolic tags.
Suppose that SRFI-X is a new version of SRFI-4 (Homogeneous numeric
vector datatypes) that follows SRFI-10's suggested protocol. Instead
#u8(0 #e1e2 #xff)
#,(u8 0 #e1e2 #xff)
and so on. If Erewhon Scheme implements SRFI-X does it implement
SRFI-10? It might or it might not. Does the user care? No, because
the user cannot tell the difference. An SRFI can comply with SRFI-10;
it is meaningless to ask if an implementation does.
The bottom line is that SRFI-10 is not about implementations, it is
about other SRFIs. This is fine, and even a good idea, but you
need to make it much clearer. Drop all the stuff about read-time
application and Common Lisp read macros. It just confuses the issue.