xxxxxx@autodrip.bloodandcoffee.net 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
xxxxxx@bothner.com   http://per.bothner.com/