This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
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 array syntax.
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 it.
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.
We disagree.
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 those systems.
It's not. We could specify: #,(ARRAY 2 int32 ...) rather than: #2A: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>) syntax?
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. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/