Re: Relative merits of Lisp-1 vs. Lisp-2?

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

In article <uver75gds.fsf@xxxxxxxxxxx>,
Kent M Pitman <pitman@xxxxxxxxxxx> wrote:

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

In article <uirna58pk.fsf@xxxxxxxxxxx>,
Kent M Pitman <pitman@xxxxxxxxxxx> wrote:

A number of options were provided for "customizing" the language, but
they
came to be properly seen, as Pascal astutely observes here, as big-switch
ways of turning the language into an implementation substrate for another
language, not really as customizations of the current language.

Sure. So? Isn't that (being an implementation substrate for other
languages) one of the things CL is supposed to be for?

Not at the expense of program combination, no.

Then why is *readtable* part of the language?

You again ignore history. The design was not "from scratch". It was
based on prior implementations. A large number of existing systems
customized syntax, so we continued that tradition. *readtable* added
modularity, it didn't diminish it, relative to prior implementations.

Also, as I said before, when things like this are in the core
language, all users are aware of them. Had you made your
*combination-hook* suggestion in the design of the base language, I
don't know that it would have been accepted (primarily because
sympathy to a Scheme-compatible style was lower then than I perceive
it to be now). However, again speaking relatively, you would have had
fewer obstacles because you wouldn't have had the obstacle of "some
programs won't know about it" since by definition (so to speak), if it
were in the language, I couldn't argue that some programs wouldn't
know about it and couldn't protect themselves.

Had this [*combination-hook*] been raised in a historical context,
though, my sense is that it would have failed because there was a
contingent who affirmatively wanted to oppose CL turning into Scheme.
But among those who were reasoning from first principles, I think you'd
have gotten the best audience by simply proposing that combinations be
allowed, period. I'm trying in this thread to articulate my sense of
the well-founded set of reasons why a hook whose sole purpose seems to
be to provide a Turing-Machine-like hook with a single end-goal purpose
would have been, and should have been, rejected.

Moreover, the right way to do this, as has been earlier noted in other
messages, is lexically, not dynamically.

DARPA would never have bought Common Lisp if we'd said "it will have
many features, but one of them will not be that applications can expect
to plug and play without prior cooperative communication to assure they
aren't stepping on each others' toes."

But that is (was) in fact the state of affairs. (Which is to say, that
applications *could* have stepped on each others toes, and still can,
but mostly don't because people by and large avoid doing the things that
cause programs to step on each other's toes.)

BTW, at the risk of stating the obvious, the economic situation w.r.t.
CL has changed since 1985. What DARPA would or wouldn't have bought 20
years ago perhaps ought not be our most pressing concern today.

You asked:

"Isn't that (being an implementation substrate for other
languages) one of the things CL is supposed to be for?"

What CL is derives from history. I did not answer in terms of today,
I answered in terms of history since that's where "intent in design"
came into play.

Your desire to dismiss DARPA as relevant today, though, denies the
fact that what we built into CL was a desire for modules to respect
the prisoner's dilemma, as I explained.

In case it went past you way earlier, I have FAR LESS concern with
your desire to support combinations than I have with your desire to
introduce a feature that allows me to implement not only combinations
"your way" but competing theories that are incompatible. You may have
thought I was being tongue-in-cheek or dismissive, but I might not be
having this debate with you if you had suggested just *ALLOW-COMBINATIONS*
of T or NIL. My concern is the needless problem of Turing Machine
willfulness that you introduce in the form you do.

If this were only about *allow-combinations*, I would mostly not have
an issue, although I do think (as noted below) that "sparseness" is a
concern. Whether that should be a dominating concern, I can't say.
But it is something that people have to weigh, and hence this issue is
still not a slam dunk.

Sections like

11.1.2.1.1 Constraints on the COMMON-LISP Package for
Conforming Implementations
http://www.lispworks.com/documentation/HyperSpec/Body/11_abaa.htm

11.1.2.1.2 Constraints on the COMMON-LISP Package for
Conforming Programs
http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm

are testimony to the intent of the vendors not to have one program step
on another.

And the existence of *readtable* (to say nothing of the absence of
first-class top-level global environments a.k.a. modules/lexicons) is
testimony to their failure to entirely achieve this goal.

I'm not sure that success/failure is so binary as you're making it out.

And personally, I think there are rules of good style that cause it to
work better.

But as I said, if you push, I'm more likely to say that *READTABLE* was
bad than that your feature is good. And I don't know to what point, since
it's not going away.

Maclisp was historically important for many things it did, but perhaps one
of its lasting contributions was the number of errors made in its design
that led us to do things better in the future...

... if we remember the lessons.

Otherwise, well, I suppose the obligatory conclusion is:

Those who don't learn from the lessons of (programming
language design) history are doomed to reinvent Maclisp.

You know, your argument amounts to this: "MacLisp did a lot of stupid
things. Therefore *combination-hook* is a bad idea." But you haven't
actually said how *combination-hook* is actually like any of the bad
things that MacLisp did.

I'll leave the coherence of my argument for others reading this thread
to sort out.

Debates rarely change the minds of the participants, especially on
issues of opinion where the participants hold strongly opposing
views. What debates do is give others who are not thus caught up a
chance to observe the ideas in play and to inform their own opinions.

I simply don't think that what I've said reduces to what you've
reduced it to, but I won't now debate that. That seems an invitation
to either get into a debate about English semantics, or else to rehash
what I've said.

I've laid out why I think what I think, and others following the
discussion will either think I'm ranting without any point (as you seem
to suggest I am) or they will not.

The same can simply not be said about an implementation extension that
is equivalently powerful. A portable application will not know to protect
itself.

Hogwash. As I have pointed out repeatedly, there is a very simple way
that an application can "protect" itself against any mischief that might
be wrought by *combination-hook*: Don't use ((...) ...) syntax. Since
this syntax is currently an error, all error-free CL code automatically
does this anyway.

If reading data that might be ill-formed, defining your language to
not signal errors about what might be a symptom of ill-formedness is
not necessarily a benign change.

I don't expect this argument to convince you. Frankly, I expect you
to dismiss my concern about this issue as irrelevant and unimportant,
even while engaging in a discussion with me about how I should not
dismiss your concern about the need for Scheme-like combinations in a
language that is not Scheme. But perhaps you will surprise me. I'm not
saying you're incapable of that--I'm just saying I don't expect it.

(I personally think the desire to use that syntax is irrelevant and
unimportant _to me_, however I do not _dismiss_ the issue nor the
arguments for it because I try to recognize the arguments,
sensibilities, and perceived needs of others as relevant to them. I
try not to weigh the absolute need in any material way other than when
those needs intrude on either a particular other user's need and when
those needs intrude on the overall design principles of the language.)

In this case, I know that "sparseness", as I've called it,
[ http://groups.google.com/group/comp.lang.lisp/msg/54067d895793587a
http://groups.google.com/group/comp.lang.lisp/msg/feed2ddf5be6e90e ]
is a design principle that I and others in the CL committee
have explicitly and implicitly relied upon at various times.

Hence, as I understand the term hogwash
1. Worthless, false, or ridiculous speech or writing; nonsense.
[ http://dictionary.reference.com/search?q=hogwash ]
you are simply dismissing out of hand the notion that I might have a
reason for my belief.

Moreover, beyond the issue of sparseness, I have repeatedly cited the
fact that your hook is so general that it simultaneously adds not just
what you want, but when you say (to re-quote you from above):

this syntax is currently an error, all error-free CL code automatically
does this anyway.

you forget that if you added the feature you want you would be
simultaneously creating a space of code for which this statement was not
true, since others might use the new hook you create incompatibly, and
hence you are proposing the addition of a feature which is its own
downfall from an internal consistency point of view.

The same cannot be said for *readtable*.

You're talking to someone who argued (unsuccessfully and perhaps only
even half-heartedly since there were mixed points of view on this,
even within myself) for the non-inclusion of EQUAL in the language,
based on the same concerns as people raised when wanting to keep COPY
out of the language. Ditto for FIXNUM.

I've said above, and I will reiterate here. *readtable* was not added from
first principles. Ditto FIXNUM and EQUAL. They were added because they were
known quantities that had been used successfully for years, notwithstanding
theoretical arguments about why they could send the language into a tailspin.
Users would have rebelled had they not been there. Since *COMBINATION-HOOK*
was not of that kind, the same arguments simply would not have applied.

Whether my arguments apply now is anyone's guess--I don't know who
your target is in this interchange. The modern market of ideas can
speak for itself--people can chime in with their present values, I guess.
But I presume they like CL and want to know how it came to be and why it
made the choices it did, and I'm offering my personal view on that. The
views of others there at the time might even differ from mine, but I'm not
asking them not to speak, nor am I trying to speak for them. I'm just doing
my part. My specialty is history, not because I was trained for it but because
I lived a least a bit of it, often as much by accident as intent since my
presence in many amazing situations was often just chance.

It is not reasonable in my theory of public debate for you
to claim that the mere possibility that you could develop such a theory of
good style is enough to trump my concern that you might not.

Well, in MY theory of public debate it is not reasonable for YOU to
simply ignore a significant portion of my position and then claim that
my position is lacking that portion that you have ignored.

I guess we've each stated our positions. Now it's for the audience to
sort out. It'll be fun to tune in CNN, Fox News, etc. tomorrow and
hear what the pundits on Hardcons and Lisp Gang have to say, won't it?

By creating situations that were mutually incompatible when loaded together.

That's probably an overbrief answer.

It's not so much the brevity as the utter lack of content. There are a
lot of things that were done back in the old days that in retrospect
were just Bad Programming Practice. I strongly suspect that the
incompatibilities were simply the result of someone doing something
obviously stupid, and not an inherent conflict between these features
that you cite.

Learning from history is rarely done by just seeing something happen twice.
You have to reapply situations that are not superficially the same at just
the right time, and not at other times. I've laid out why I thought this
matters. I hear you as saying you think it doesn't. Again, I'll be watching
the pundits to find out whose argument was more persuasive.

But I don't have time for something better.

That's a pretty lame excuse. It's pretty unfair of you to cite an
example in support of your position and then fail to explain how it
actually supports your position. It leaves people with the impression
that you have actually supported your position when in fact you have not.

Fair or not, I have finite time. It also seems unfair that in a
supposedly expanding 4-dimensional universe, only space is expanding
and not time. You'd think we'd find that as time went on, we'd get not
only galaxies moving farther apart, but hours as well, so that we had
more and more time to post on comp.lang.lisp.

As so recently noted, I have spent a lot of time away, and I'm at risk
of that again. I have a heavy schedule of work. My goal in my
participation here is less to win or lose a debate, and more to upload
information from my brain into a more durable form. I trust that if I
have not seemed coherent to you, I may have to someone. Or, if not, then
speaking longer won't help things. If I'm just babbling incoherently,
better I cut that off than make people wade through twice as much babble.
It sounded to me coherent, but maybe that's just an advancing dimentia
setting in... or maybe I was just never coherent in the first place.

.

Relevant Pages

  • Re: Smart programming languages
    ... common "top down" approach to language design. ... E.g, Suppose you have three language features A, B and C. ... make C a high-level feature implemented in terms of A and B. ... provide programmers with all 3 features. ...
    (comp.programming)
  • Re: Why return None?
    ... > That extend doesn't work for strings and tupples is irrelevant. ... If lists were being designed from scratch today, ... A "greenfield design", an entirely new language designed from scratch, ...
    (comp.lang.python)
  • Re: (Falsifiability is binary) Re: Textbook text candidate
    ... recognise design in the abstract without reference to the methods ... volume and strength of the evidence, ... You have a linik to a language aquatitional page. ... and right up and down why would aliens not use a similar form. ...
    (talk.origins)
  • Re: Java or C++?
    ... > its current design. ... The current C++ thinking is to avoid core features of the language like ... I like the typedef feature and would like to see ... D supports functors by supporting overloading of for structs and classes. ...
    (comp.programming)
  • Re: [Lit.] Buffer overruns
    ... this is a long rant about the links between language ... Both to some extent but definitely worse within the C community than in, ... >> culture (I am contrasting Ada and C only because I have a lot of first ... culture of low level design that it has unwittingly fostered. ...
    (sci.crypt)
Loading