[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
Interoperability [between Scheme and Ommon Lisp] is impossible anyway.
It's certainly tricky, though I try in Kawa. I've implemented a
small subset of Common Lisp and a larger subset of Emacs Lisp.
How do you deal with Common Lisp's package system?
That's not that big a problem - one can assume all Scheme symbols
belong to a single package. Worse is dealing with #f / nil vs ()
all being different in Scheme, but not in Common Lisp.
Moreover, there _is_ a good reason for having a SRFI-10-bases syntax as
opposed to Common Lisp's #\a octothorpe reader syntax: to make Scheme's
syntax simpler & more consistent. This is not just simply a nice thing
to have, but one of the hallmarks of Scheme in the first place. It is
_not_ a good idea to complicate it totally unnecessarily, just to
retain a vague notion of compatibility with old, crufty Lisps.
You're right in tha using the srfi-10 syntax for arrays is not crufty.
It's much worse than that ...
I think it would be perfectly fine, except for backwards compatibility
problems, to flush the #(...) vector syntax in favour of a more general
Perhaps we should should flush the (a b c) syntax for #,(list a b c) ?
I'm confused as to why using SRFI 10 makes things
'second-class,' however. What makes SRFI 10 degrade the class of what
it is used to represent? There seems to be a great deal of aversion to
SRFI 10 here that I don't understand.
It's aesthetic. If you don't understand it, I don't know how to explain
So they can keep doing so. Making the #,(ARRAY ...) syntax standard
wouldn't hurt them. Making the #nA...(...) syntax standard, however,
_would_ hurt simplicity & consistency in Scheme's syntax.
OK, but you still haven't given a decent justification of Common Lisp's
array syntax. All you've said is that you like a couple of features
that Common Lisp supports.
It's terse. It's stylistically consistent with vector notation:
#(a b c) - can be viewed as short-hand for #1a(a b c). It doesn't
require me to write an extra noise keyword. It's prior art.
Perhaps I'm missing the point you were trying to make here, but I don't
see how this is a good example of how type specifiers could work in
standard Scheme: you've demonstrated that Kawa has a syntax capable of
assigning Java classes/types to Scheme variables, which affects the
Java byte code that is generated. This does not seem very useful for
other Scheme type systems or for array element representations.
A standard syntax for optional type specifiers would be extremely
useful. Many Scheme implementations could ignore the specifiers,
but they would still be useful for documentation. Other implementations
might check at run-time that a value matches a type specifier, which
is useful for debugging. In that case we view type specifiers as a
limited language for machine-checkable assertions. Some implementations
can use assertions for code optimization, and static error detection.
I agree that optional static type annotations can be useful. However,
they are not only _far_ outside the scope of this SRFI but also ill-
suited to the matter of describing array element representations.
A subset of type specifications for "atomic" (mostly numeric) types
is clearly useful for both.
OK, it seems we violently agree here that the element representation
specifier should be cleanly separated from the ARRAY token, although I
don't consider ARRAY:INT32 to have a clean separation: it would read as
an atomic symbol to Scheme.
Why is that a problem? But note I'm not suggesting array:int32 for
srfi-58; just that *if* a Scheme supports type specifiers, and uses
int32 as a specifier for 32-bit exact integers, then array:int32
might be one possible syntax for a type specifier for arrays whose
elements are int32.
however, I don't see how my proposed SRFI-10-based syntax, #,(ARRAY
<rank> <elt-rep> <contents>), is intrinsically incompatible with all of
It's not. We could specify:
#,(ARRAY 2 int32 ...)
The former is perfectly compatible with a type specifier model.
I still don't like it.
Or perhaps I misunderstood and you were referring to
the current #<rank>A<abbreviated-element-representation>(<contents>)
I dilike that because it's incompatible with a type specifier model,
and I also think it's ugly. But it is compatible with Common Lisp;
however, as you say, that's not enough.