Re: Beyond CL?



"William D Clinger" <cesuraSPAM@xxxxxxxxxxx> writes:

> Pascal Costanza quoting me:
> > > Interoperation with Common Lisp is no longer viewed as
> > > a major issue.
> >
> > I am surprised. Was that ever a goal?
>
> We're talking about compatibility of external representations,
> which was important to a number of people during the 1980s.
> The most influential of these people drifted away from both
> Common Lisp and Scheme during the 1990s.

(Is there some reason you can't say this person's name? Perhaps he/she
doesn't want it known that he/she is so influential? Perhaps the drift
is a secret? ...)

Will, I hope you're not suggesting that this loss was caused by CL's
lack of caring about these issues, or that Scheme has been the eternal
champion of such matters. I certainly sat in lots of Scheme design
meetings where I pushed for obvious things like branch cuts, error
handling, and other "useful" things and was told that such things
would either (a) increase the size [i.e., page count] of the spec
[something some authors absolutely were not prepared to do] or (b)
make the language "too useful" [thus meaning too many people would
flock to it and it would be the end of the designers' ability to do
the things to the language that _they_ wanted to do].

The main point I was making above is that the history of how we got to
where we are today with both languages is relatively complex, and
there are many points of view. So perhaps we should leave history
aside and focus on what can be done today. I almost get the sense
from your remark that you think it is a lost cause to think the CL
community would care about these matters and that's why you are being
so (over)brief. I hope that's not so. I think there are potentially
interesting things that both communities could gain from some back and
forth dialog about what's going on with this in the Scheme community.
I hope you will periodically share thoughts on this if you're plugged
into the ongoing process.

Here are some starter questions for you:

Symbols. Certainly the issue of symbols is a minor irritant, but I
haven't seen that be a stopping point for Scheme emulators written in
CL. I recognize that you don't like the CL package system, but why
can't you just ignore it, make a single package you do like, and use
that. CL specifies nothing about the layout of symbols anyway, only
about their accessors. Why exactly is this a problem in callout, since
most languages other than Scheme don't have symbols, and since in Scheme
most people just use symbols in the CL SCHEME package and ignore other
symbols. If appropriately abstracted, isn't that enough?

Continuations and Tail-Calling. There is a well-known issue over
continuations and tail calling that I won't open here since I assume
you're not saying that's an issue of datatype layout.

Numbers. CL has numbers that are pretty much able to be type-compatible
with IEEE standards, except that we have a representation for rationals.
Scheme has a bunch of types that are non-standard. What is the criticism
of CL here?

Structs. Both CL and Scheme have opaque types for which you are not
told the specific data layout. Are you saying you're going to start
specifying it, so that people can pass structs directly to other languages?
If so, that's certainly interesting. How will this interact with the GC?
How will you manage tag bits? If not, then how is what you do different
than what CL does?

Manifest types and pointer indirection are always issues, since
building recursive structures in Lisp without re-tagging the
recursive parts is tricky. (In languages that are statically typed,
you can build a tree or other recursive type where type info is
implicit in variables and slots but not manifest in all the parts.
This saves some space at the cost of some flexibility and is a
relatively deep design trade-off that most of the Lisp family
accepts. In just a few seconds' thought, it isn't apparent how
Scheme could do any better at the specification level, though
certainly I could imagine some block compilation of Scheme doing
better by special-casing.)

Characters and Strings. You have remarked about Unicode in specific.
I'd be interested to hear what you think is a problem about CL in
Unicode. I mention this specifically because very late in the CL
design process, the Japanese subcommittee studied the issue of CL's
character and string types specifically and gave us a report on what
we would need in order to keep from being incompatible with
international character standards at the time, including subtle issues
like providing for external formats in files, etc. different from
chacter coding issues for "in core" characters. We made all of their
recommended changes, and while we don't provide specific support for
Unicode, my understanding is that several conforming implementations
do provide such compatibility. So what's your specific critique of CL
other than that it simply needs a new layer that defines additional
functionality? I hear an indictment, but no specifics.

In general, there is nothing in CL that precludes implementations providing
additional datatypes that are compatible in specific layout with other
languages, but neither is there anything that requires much in the way
of specific layouts other than strings, which are problematic for all
languages because of the issue of char[] vs string, and whether size
is a constant time operation or not.

Anyway, I'd like to hear your critique of where CL has ignored something it
could or should be doing, or where Scheme is adding something that perhaps
CL could add, or where the languages have simply made different choices and
what the implications of those choices are. You seem to be commenting on
some such difference, but absent more detail I cannot figure out what, and
without more exposition I am / we are incapable of learning from what you
appear to know...
.