[netsettler]

I dunno about expected and encouraged. Neither really, nor discouraged though. Really the point was that this was written in the context of a particular standardization effort and was to say "this is out of scope". As it happens, RPG and I disagreed completely on whether Lisp1 or Lisp2 was a good idea. Most readers read this like a Rorschach, assuming that the article confirms their own beliefs, not stopping to think that the article just presents two sides of an issue. In the context of the design process, Lisp2 won out (and I happen to be happy about that). But it is reasonable and appropriate for both to thrive if there are users who like those sorts of things.

I created the Lisp1/Lisp2 terminology as a dodge because we started out writing this paper using terms something akin to "Scheme-like" and "CL-like", and Scheme was winning for reasons unrelated to the issue at hand. I wanted people to separate their warm fuzzies for Scheme from the particular design choice, as I really think there are very strong and reasonable reasons to have a Lisp2. The net result was that in the context of CL, those of us liking Lisp2 successfully argued that it was an unnecessary change to the language from a stability standpoint.

This paper is called "Technical Issues..." because the committee document (titled "Issues...") was longer and went into other issues that RPG didn't think were pertinent to formal publication.

I frankly don't understand (or perhaps don't agree) with any claim that Lisp was looking to condense namespaces. By convention and John McCarthy's official request, Lisp is the name of a family of languages, not of a particular language. Lisp has no preference. It spans languages with broadly varying points of view.

Ironically, CL is really at least a Lisp4, by the way. block tags and go tags are legitimately different namespaces. They just messed up the discussion so we left those out. Whether you also count the type/class homes as a namespace is something that doesn't fit neatly into the terminology so is the reason I say "at least a Lisp4". Left to personal subjectivity. -kmp

[aerique]

I'm not trying to start a flamewar here but could you go into why your preference is with Lisp2 instead of Lisp1?

A lot of commenters here have a strong preference to Lisp1's so I'd be happy to hear a different point of view.

(Disclaimer: I'm mostly a CL user and appreciate it being a Lisp2.

Also, nice to see you here! I always really liked your posts in comp.lang.lisp.)

[Grue3]

Not having to name your list variables "lst" is a big one.

[netsettler]

Yes, I am with Grue on this one. The overcrowding of namespaces means the very common case of receiving a thing that is known by its type (list as "list" or "string") occludes a common constructor that you might want and makes you spell it badly. I really very strongly prefer proper spellings of things, but moreover I think this is "natural" in a way that is neglected in this discussion.

Simplicity can be measured in different ways, and there is a tendency in the Scheme community to think of simplicity as a measure of the size of a formal semantics. But two things come to mind about that metric: (1) I have often claimed that small languages make big programs, and big languages make small programs. So to some degree it's the case that tiny languages mean you have to laboriously reconstruct as program or library what the language did not let you do in its zeal to not offer functionality. (2) Human beings are not designed in the Scheme way. The natural languages include no language at all, out of many hundreds, in which words have only one meaning and do not enjoy contextual distinctions. So in my view, simplicity can also measure the lack of dissonance between the program model and the brain model. My brain is, I believe, well-adapted to understand word meanings differently for noun and verb, and Scheme affirmatively chooses not to rely on that, leaving my brain bothered by the lack of ability to use it natural mode and forced to use what seems more cumbersome. I don't want to reach for more words, I want to use obvious context. And I claim that this is at least a valid way of thinking, if not uniquely valid. I'm not trying to disallow the way others think (or think they think, we being poor at actually introspecting sometimes), but to say that the way others think is no more or less valid than my own.

This is, as Aerique implies, somewhat a religious matter and not to be warred over. So I don't want to provoke debate on whether my way is THE right way, only A right way among MANY simultaneously right ways.

At another level, though, this is the very essence of what it is to be a CL user, or a member of the CL community, at least in my mind: The language expressly accommodates and encourages a pluralistic society in which multiple paradigms are simultaneously supported. I don't want to accuse the Lisp1 community of being a bunch of intolerant folks, but I will note that in my mind it's hard to escape the sense that it bears a striking resemblance to that. It's a community that wants people to learn the Scheme way, not a community that wants to accommodate the various ways people naturally think.

I keep coming back to the old joke "There are two kinds of people in the world: People who think there are two kinds of people in the world, and people who don't."

CL has preferred casifications, but expressly goes out of its way to accommodate others. It has ways of thinking about loops in various paradigms. It has macros and read syntax things for letting you override almost any decision that we could figure a way for you to override. There are places where we do a poor job or an incomplete job, but that's more an artifact of the energy and funding than of design. There was pressure to reduce out the redundancy and we opted not to.

People think in multiple namespaces. We know that when you license a production you can create a license (British respelling notwithstanding, it is possible to use the same word in different contexts without confusing whether it is a noun or a verb). In Spanish, a normal speaker would not flinch at the sentence "Como como como." (I eat how I eat, where the middle "como" is "how" and the outer two are "I eat".) These are natural, and so simplicity in this context, at least for me, is being to write thing the way I think.

The imagined need to crowd out these names doesn't really come up in CL. Nouns and verbs mostly operate in different orbits and don't interact, and that feels pretty natural. Languages are more about ecologies than about a la cart features, and there's a danger in liking a feature and thinking it can just be injected into an ecology and will behave either as expected or even just pleasantly.

[kazinator]

Although I'm with you on the issue of some Lisp-1 people being parochial, we can argue that "como como como" is an example of something bad that we don't necessarily want in a programming language. Not everything natural, in natural language, is good in a computer language. Never mind that a word can be a noun and verb in different ways: in natural languages, even if the word has the same role, like noun, it can have different "bindings" at the same time in that same space due to homonyms. Do you want the same symbol to have several completely unrelated global bindings in the same space, the dispatch being resolved based on semantic context (perhaps not even known until run-time)? Ouch.

Simply the fact that you have exactly two namespaces, in each of which there can only be exactly one binding for a symbol at a given lexical level, is different from natural languages.

I'm convinced that Lisp-2 and Lisp-1 have merit, and made a Lisp dialect that offers both, in a reasonable way that manages to be relatively clean.

An ideal Lisp dialect supports the reasonable request of him or her who wants (list list) to Just Work, and it supports that programmer also who has a function-valued variable f and just wants (f x y) to work. That ideal, if taken too literally, is contradictory, but an acceptable compromise is to have [f x y] work, where [] changes the evaluation of atomic forms that are bindable symbols to Lisp-1 style (utterly, with deep support from the macro-expander and evaluation semantics).

[netsettler]

I am totally comfortable with funcall. It is my preference, not something I bargain down to. I don't have a need to have (f x y) "just work". You needn't agree. I acknowledge differing tastes here. But you need to, as well. It is not proper to speak as if we obviously have the same goals. We do not. It is not that we have the same goal and are differing on tactics. We have actually different goals. That is important to see or else you cannot wrap your head around why the issue played out as it did.

As you say, notational games can be played. And there are other approaches. Just because people have different goals doesn't mean that's the end of discussion. But an honest discussion must recognize the legitimate desires of both sides without disparaging one side. Getting inside another's head is important.

I don't pass functional arguments a lot. CL programmers often don't. Where Scheme would pass functions, CL often uses keyword arguments. In sort, for example, we customize behavior not by passing some function but by passing a list of keywords. There are places we pass functions, but it is not our ordinary business. So calling it out, by doing (funcall list...) rather than just (list...) gives a signal that something unusual is happening. If you plan for this not to be unusual, you will go a different way. But we do not all aspire to pass functions at every point. I like having it for certain purposes, but doing things in other ways as well.

For another take on a middle ground than the character syntax you describe, see my http://www.nhplace.com/kent/Half-Baked/spiel/index.html

[netsettler]

> Do you want the same symbol to have several completely unrelated global bindings in the same space

Absolutely. Yes.

[kazinator]

Are you sure? Global, in the same space? As in X having three different bindings as (say) a variable, at the same environmental level ("top-level")?

[netsettler]

Thanks. Not sure how notifications work here, but I replied to your comment as a reply to Grue below this, so check the page.

[taeric]

My claim for the Lisp community wanting to condense is strictly colored by my (possibly incorrect) view that every Lisp since has been a Lisp1.

I have not personally taken too deep of a dive on Lisp1/Lisp2. Reading your response, I get the impression that this was actually a somewhat contested choice. I have to admit, I'm not clear on why I would personally care. Are there hard reasons to prefer one over the other? (In particular, I have not seen any advantages for either way explored from a user perspective.)

I'll have to read this particular paper in more depth, so apologies if the answers I'm asking for are in this article.

[ScottBurson]

My own take on it, in a nutshell, is that while Lisp-1 has a certain elegance which is attractive, it makes the macro hygiene problem much worse (sections 6 and 13). I've seen it claimed that there's never been a really good solution for this in Scheme, though I've never written much Scheme and haven't attempted to evaluate this claim personally. In any case, I'm very much accustomed to how one does things in Common Lisp and don't mind either its Lisp-2 namespace-crossing operators ('function' and 'funcall', section 5) or its "low-level" macros.

I also tend to think that far more electrons have been spilled over this issue than it deserves. It's an engineering decision with tradeoffs either way; there's no god-ordained right answer. I'm sure that if I were trying to decide whether to write a large system in Scheme, its being a Lisp-1 would be the least of my concerns.

[netsettler]

Hygiene is still needed in CL, but is accomplished in different ways that are not so explicit. Packages and namespaces end up doing most of the heavy lift, so CL's macro system, while it looks more raw than Scheme's, is still pretty robust. And many of us just find it simpler because it involves a lot less mechanism. (Odd that in that isolated realm of macro processing, the Scheme system is complicated and CL is not. You never get anything for free--you just trade one thing for another. Laws of thermodynamics and all that. They're hard to escape.)

[taeric]

I did find that most all of my questions were directly addressed in the paper on a slow read. I should have picked up on them in a fast read.

Your second paragraph seems to hit it on the head, though. Since most of my exposure was to scheme and racket, I have not looked deeply at Lisp2s. However, having switched to emacs and written some elisp, I have yet to really be annoyed by the fact that it is a Lisp2.