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

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

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

There are lexically scoped versions of my proposal. Why do you ignore
those?


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.

Just for the record, I would be perfectly happy with a boolean
*ALLOW-COMBINATIONS*. (That was actually my original suggestion.) I
changed it because there was disagreement about what the semantics of
combinations in CL ought to be.


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.

I'm not making it out to be binary. Note the highlighted word.


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 do not dismiss your concern as irrelevant or unimportant. I will
point out the following however:

1. This argument would apply to *any* proposed new feature, not just
*combination-hook*.

2. Lisp already has a feature called macros whose entire purpose is to
take data patterns which were previously ill-formed and render them
semantically meaningful. Not only is this feature not generally
considered to be non-benign, it is considered by many to be of high
utility.

3. I don't have any data to back this up, but I strongly suspect that
cases of programmers accidentally typing combinations into their code
are quite rare. Cases where such accidental combinations would
accidentally lead to semantically meaningful behavior in the presence of
*combination-hook* would be rarer still.

4. At the risk of repeating myself, any program can insure complete
protection from any potentially deleterious effects of
*combination-hook* simply by insuring that it is set to its default
value.

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.

Not at all. I simply think that your reasons are without merit (which
is not the same thing as dismissing your beliefs as irrelevant or
unimportant. If I thought that I wouldn't bother to respond.)


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.

Yes, that is a legitimate concern. My answer (again at the risk of
repeating myself) is that this is also true of features that are already
in the language and empirically we have not ended up with a morass of
incompatible libraries due to judicious use of these features. There is
no reason to expect the situation w.r.t. *combination-hook* to be any
different.


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.

Yes, I know. Do you believe that subsequent history has vindicated your
position? In other words, do you believe that the inclusion of these
things in the language has resulted in substantial damage? How do you
think the world would be different today if you had gotten your way?


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.

And in retrospect do you think that those theoretical arguments were
correct?

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.

But users *do* rebel. But the rebellion is not as visible now because
they rebel by using Scheme (or Python).

Whether my arguments apply now is anyone's guess--I don't know who
your target is in this interchange.

Aren't you curious?


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.

So you don't have time to write anything to explain why cxr and hacky
strings introduce fundamental incompatibilities into the language, but
you do have time to write three paragraphs explaining why you don't have
time.

OK.

rg
.

Relevant Pages

  • Re: Graphic GUI C
    ... features in C99) is also a feature of C++. ... expect the C language and the C standard library to do everything; ... nothing is more commonplace than the need for one or more libraries in ... The same is true inside of WSH where all of the functionality ...
    (comp.lang.c)
  • Re: Hows dot.net doing nowadays?
    ... Actually there are feature more important than others if you look at ... The ability to combined subroutines with the data ... The feature that gives the most trouble is Lisp ability to ... the database engine but Lisp can do it within the language itself. ...
    (microsoft.public.vb.general.discussion)
  • Re: Whats the deal with C99?
    ... be in the language. ... languages by itself speaks volumes about what programmers want. ... There's no feature added to C99 that addresses even one thing that has ... There's no controversy about memory management? ...
    (comp.lang.c)
  • Re: Need Help Creating an Image Slideshow
    ... ;' fails? ... is not part of a programming language ... You know I am an advocate of feature detection - I'm using it all the ... time - but not in absurd cases like this. ...
    (comp.lang.javascript)
  • Re: BBC - Railway closes as owners bail out
    ... League of heritage railways and I tend to dismiss those lines that ... feature mostly ex-industrial locos and diesels. ...
    (uk.railway)