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

JesusWaffle@xxxxxxxxx writes:

What are the relative merits of a Lisp-1 (one namespace for both
functions and variable) versus a Lisp-2 (one namespace for functions,
and one for variables)? I can think of the following:

For Lisp-1:
* No #'
* It's always clear what a name refers to; can't do potentially
confusing things like (foo foo)
* Somewhat simplified language description, somewhat simplified
implementation

For Lisp-2:
* Can't accidentially shadow function names (especially important for
safe non-hygienic macros)
* The size of the namespace is doubled, because you can reuse each
name twice

Looking at the above lists, I would tentatively choose Lisp-2, since
the arguments for Lisp-1 are mostly aesthetic, and the arguments for
Lisp-2 are quite practical. But, what do you think? Are there any items
you would add to the lists?

For Lisp-1 For Lisp-2

* No #' * #'

That is, No #' is a goal of people who want no #'. But some of us WANT
#', so make sure to have "#'" as a positive on the other camp. It's easy
to have this discussion go awry if you assume everyone is trading against
the same sets of goods and bads.

Consider one extreme end of the abortion debate, disregarding the other:

For Pro-Life: For Pro-Choice:

* No babies killed. * Babies killed.

This does not fairly reflect the debate. Because from the pro-Choice side,
the issues are not viewed symmetrically. That is, from the extreme end of
the other side, consider:

For Anti-Abortion: For Pro-Choice:

* Mothers raped and enslaved. * Mothers not raped and enslaved.

This, of course, doesn't capture things either. Properly placed, you have
to assume that some people are simply perceiving and valuing things
differently such that a fair analysis shows

For Pro-Life:

* People who perceive that this issue is all about life
find that avoiding abortion avoids messy moral issues for them.

For Pro-Choice:

* People who perceive that this issue is only somewhat about life,
since for some of them life does not begin "at an instant" or else
the soul does not "enter the body" at a known time or "a mother's
already invested life is to be weighed differently than that of a
few cells which has no investment" or ...

My point here is to give you a framework for understanding a debate in
which the sides simply do not have the same goals, frames of reference,
etc. It is very difficult to reach common ground, and it is even more
difficult if you assume that there must be a single solution.

To get back to Lisp1/Lisp2, the thing I find most frustrating is not
the relatively simple issue that there are two different worlds here,
but that a lot of the debate often takes on a meta-flavor of "one of
these worlds must be shown to be uniquely Right and the other uniquely
Wrong". I also find it somewhat amusing and somewhat sad that in my
experience, the people who line up to push Lisp1 often do so not just
because they like the list of features Lisp1 has, but because they
often seem to project a sensibility about the world that by force of
will they can make it more simple and effectively rule the issues of
the more complex world to be "out of bound" or "improper". So it becomes
a meta-debate of the form Language1/Language2, where in one world you
have only Scheme but in the other world you admit that both Scheme and
CL have a legitimate place, and it seems so much simpler to say that there
should be only Scheme because the option of living with both Scheme and
CL seems impossibly awful. On the other hand, the advocates of Lisp2 seem
to so much more often say "I could tolerate sometimes using Scheme if I
didn't have to think I had to use it all the time." So there's the same
kind of odd bias as I often find in the abortion debate, where if you listen
carefully, it's as if the pro-life community thinks the pro-choice people
are saying "always abortion" when they're saying "think about it". Choice
is about tolerance, not about pushing one's way. Lisp2 is about choice,
not about pushing one's way.

I'm actually rather a fan of Lisp Omega, I just haven't seen it worked
through. I tried and failed with my meager available time in my
http://www.nhplace.com/kent/Half-Baked area.

And so I come back to the notion that the reason CL has #' is not just
a "patch" where it couldn't figure out how not to, but many of us like
having a marker on something that says "I'm using this name as a function.
I don't do that very often. Take note." To do without that would be to
risk confusion. So we find it comforting. It's almost uniformly assumed by
the Lisp1 community that all people would find #' offensive, but you can
count me as someone who does not.

I can understand the desire to not have to use it, but that's really an
orthogonal point. CL could have been designed not to require it, and it's
easy enough to write a binding form that sets up the situation on a by-need
basis, it just can't be done to make binding "generally" do that.

Going back then to your chart:

For Lisp-1:
* It's always clear what a name refers to; can't do potentially
confusing things like (foo foo)

I'd add:

For Lisp-2:
* It's always clear what a name refers to; can't do potentially
confusing things like (foo foo)

That is, both of these things are always clear. It's just a question
of what they mean. One means "call the function in fname foo on itself".
The other means "call the function in fname foo on the object in variable
foo". I don't see that either of those is unclear.

You wrote:

For Lisp-1:

* Somewhat simplified language description, somewhat simplified
implementation

I'd add:

For Lisp-2:

* Somewhat simplified programs.

That is, every time you make a language do more, you make programs do less.

Then again, Scheme makes the language do more with macro hygiene. That is
not a simplification of the implementation, and it's probably not even a
simplfication of the language.

It gets quite complicated to talk about simple and complex because when
things have consequences, and consequences are able to combine into the
infinities, counting consequences and assessing complexity is often more
complex than people who want a simple, fun debate are willing to do.

You omit another point entirely: which language is "more isomorphic to
how people think". I claim (without proof, alas, but at least I'm being
up front about htat) that a language that is "more like people think" is
easier to reason about. The Lisp1 people often assume "simpler" is what
makes it easier to reason about, but I'm not sure that's the same, and I'm
not sure it goes without saying.

I make the bold (albeit scientifically unsupported) claim the Lisp2
model is more isomorphic to how people think. I base my claim on the
observable fact that are no extant human languages in which any word
has only one meaning, suggesting to me that humans have tons of
wetware for dispatching for meaning based on context, which wetware
would be going to waste if you were to only have one assigned meaning
at any given time.

The claim that is often made in reverse by the Lisp1 community is that
it's easier to teach the Lisp1 way. That reqires proof, though they
rarely assume so and rarely offer any; humans often know immediately
about the notion of context-dependent meaning and are surprised when
they can't use it to get out of a bind (pardon pun) they've made for
themselves by global naming in a Lisp1. The entire biz of macro
hygiene may be regarded as elegant by the Scheme community but is
rarely offered in the context of discussion of "decreased language
size" for not having lisp2. Yet packages+lisp2 is the reason there's
no semantic problem in CL like what was in Scheme was unusable absent
hygiene because the language design made things too cluttered.

You write:
For Lisp-2:

* The size of the namespace is doubled, because you can reuse each
name twice

So double an infinity is bigger, eh? Hmmm. I'm not sure I really buy
this one. I think you're better off making an argument in terms of
what I'll call "intellectual real estate". I've often seen in the law
make a difference between "real estate" and "ip" based, as far as I
can tell, on the notion that land is "real" and "finite" and therefore
has intrinsic value in a way that a copyable or destroyable commodity
does not. But if you examine intellectual property more closely, you
see that IP is not devoid of real, exhaustible commodities. The lack
of short names in any language or naming system, such that the
desirable names will always go for a better price. This explains why
short names sell for more in the domain name system on the internet.
Of course, there's no end of ability to make new namespace systems,
but even those will eventually fall victim to a naming problem, and at
some point the length of the naming system will be too long and you'll
need meta-naming systems. But within any one of these, there's
competition for the short names or for other scarce resources ("screen
real estate" has long been cited, and is a kind of specific instance
of this). So the issue isn't about the number of names, but about the
number of names you'd reasonably be willing to use, and that number, while
people might disagree on it, is something most people would agree is
quite finite. So I will say that the number of available "good names"
is doubled, which is much more interesting than the whole namespace
being doubled.

Then again, mixed alphabetic case could do a lot more than this issue ever
will for adding names, so maybe it's a point without a difference.

- - - -

I personally like Lisp-2 because it reflects how I really think about
names. If I know a person named John, I never get him confused with
where to go to the bathroom. "the john" and "John" are just different
and their grammatical use is enough to make sure there is no difference.
The idea that a program should be randomly insisting that in all contexts
I mean the same thing is just laughable to me.

Do I mind someone inventing a language that does this? No, I'm able to
tolerate a lot. Tolerance in the world makes room for a great many
fun things. Intolerance does not. My life is enriched by others doing
things differently, even on their own terms that surprise me. My life is
not enriched by people inventing reasons to phase me out, nor do I suspect
that theirs is thusly enriched either. I therefore use Scheme on its own
terms, but I expect CL to behave on its own terms. I continue to believe
that a language in the Lisp Omega style could bridge the gap, but it's
not something that's been shown. I think it could be a fun thesis for
someone...

Incidentally, if you read Gabriel's/my Lisp1/Lisp2 paper, you'll see there
are also some speed issues you didn't address in your discussion. A Lisp-2
is capable of being faster without a lot of additional proof technology.
It can make some better assumptions about why people are using variables
than an all-purpose one-namespace system can. A Lisp-1 can make up for that
in most cases by clever compilers, but that's far from "for free".

.

Relevant Pages

  • Re: How to update an agrument passed by name in scheme
    ... people say "say how much easier it is to do this thing in Scheme as opposed to whatever other language". ... But passing by reference is exceptionally easy in some of those other languages, and not so easy in Scheme, which, based on this thread, cannot be done trivially. ... that foo is an ordinary procedure, then without even knowing what foo does, we can safely conclude that the result of the expression is 5. ...
    (comp.lang.scheme)
  • Re: seperation of function namespace
    ... Yes, but name clashes still happen and idiotic naming ... Because the way the English language graphemically conflates verbs and nouns ... PLT scheme and related publications). ...
    (comp.lang.lisp)
  • Dissecting the electorate
    ... Scheme needs *no* additional modularization ... would be quite a bit more painful to use than the language we ... Now, getting the module system *right* is not necessarily easy, ... from the core semantics and into the library - the C stdio libraries ...
    (comp.lang.scheme)
  • Re: Batch conversion of files
    ... tried writing those other languages in Scheme. ... one would want to do in GIMP is a procedural task. ... cleaner code that would have been written in another language more ... Let's take that simple batch mode script that caused all the fuss to ...
    (comp.graphics.apps.gimp)
  • Re: Ideas for an SICP?
    ... language at the same time. ... I don't believe it is impossible either, but I do believe the scheme ... If Clojure can solve these problems, ... For the purposes of the original topic of this thread, a new SICP ...
    (comp.lang.scheme)