Re: How Common Lisp sucks

Ron Garret wrote:
In article <4ajjuuFtfulqU1@xxxxxxxxxxxxxx>,
Pascal Costanza <pc@xxxxxxxxx> wrote:

Ron Garret wrote:
1. CL lacks standardized support for many operations that are necessities in today's world (e.g. sockets, database connectivity, foreign functions). Moreover, it lacks any mechanism by which these features could be standardized.
It lacks any _sanctioned_ mechanism for standardization. There is certainly a mechanism for creating defacto standards.
That's news to me. What is it?
It's a three-step process, and consists of: 1. Writing code, 2. publishing it, 3. getting acceptance of a considerable number of members in the Common Lisp community.

"Considerable number?" That's pretty vague, isn't it? And what constitutes acceptance?

I know it when I see it. ;) Yes, that's vague, but it's good enough. (Consider something in an official standard that noone uses. Would you call that "accepted"? I wouldn't.)

What matters in today's world varies heavily across different users of Common Lisp. A sanctioned standardization process would have to somehow deal with making a decision what comes first. This has the danger of leading to a large amount of bureaucracy, and furthermore doesn't guarantee in any way that newbies' needs are addressed.

True, but the lack of any such process guarantees that these needs will not be addressed.

Only if that were the only way to address these needs.

Es ist nicht gesagt das es besser wird wenn es anders wird. Wenn es aber besser werden soll, muss es anders werden.

Es ist aber schon auch wichtig, was das genau bedeuten soll, denn es sollte klar sein, dass nicht jeder beliebige andere Weg zur Verbesserung beitragen kann.

The same holds for global dynamic variables: If you use them before you have defined them, you are invoking undefined behavior. So there is no difference between global dynamic and global lexical variables here.
Aw, geez, let's not descend into quibbling over these details. You know perfectly well that every implementation handles an undeclared free variable reference by assuming it's a dynamic reference.
No, I don't know that perfectly well. I try to stick what ANSI Common Lisp specifies as far as possible in order to be sure to be portable, so that I have to worry less. Furthermore, I had the impression that you are concerned about sanctioned standards. Now you are apparently invoking a defacto standard.

This is one of the very few instances of behavior outside the standard where every single implementation works in exactly the same way, and in the one case where an implementation didn't work that way (CMUCL) people screamed loudly until they changed it.

Doesn't matter. It's not covered by a sanctioned process, it doesn't support your point of view.

I think that 'always define variables before you use them' is a far better description for a newbie than 'define special variables whenever you want because most implementations treat references to such variables as special anyway; if you happen to encounter an implementation that doesn't do this, you're screwed, and then you have to rearrange your code; nevertheless, symbol macros should always be defined before their use'. There's something wrong here.

How about, "If you forget to declare a global variable before you use it then it will be treated according to the code transformation specified in the built-in global variable *undefined-global-reference-hook*. By default this hook generates an error (which on a strict reading of the standard it is), but you can redefine this behavior if you find it annoying.

This would have unpleasant side effects on other parts of the ANSI Common Lisp standard, and it would be a daunting process to figure out all the consequences. For what purpose? I still think my explanation is easier to understand by a newbie than yours, your suggestion rather looks like a hook "for experts", so I don't think this would attract more newbies.

Meta-comment: Such a discussion is important. If we don't find a single example for changing the language in a fundamental way that would actually make the language easier to understand for newbies without loosing expressiveness (!), then this point is moot.

What if I don't want a Lisp-1? What if I want a Lisp-2 that handles ((...) ...)?

That would lead to an inconsistent language.

Furthermore, it is not even necessary to agree on the semantics of ((...) ...). One could simply add a new macro defining form (or even a global variable) to set a user-definable hook for transforming expressions whose CARs are lists that do not begin with LAMDBA. All that would need to be agreed upon is the name of this form. Furthermore, this would result in strictly greater expressive power. It would be strictly backwards-compatible. And It would serve the needs of a number of users who are not currently being served (e.g. those who prefer to do functional-style programming without having to type FUNCALL all the time.)
You would have to define a way to delimit the scope of the different possible hooks, otherwise it becomes a nightmare to try to mix and match different third-party libraries.
Fine, make it a hook function then. Now all we need to agree on is the name of the variable.
How do you ensure that hook function 1 is used in your library but hook function 2 is used in mine, when both libraries should be used in the same program?

(EVAL-WHEN (LOAD-TOPLEVEL) ; or whatever the right one is -- these always confused me
(SETF *NON-LAMBDA-LIST-CAR-MACRO-EXPANDER-HOOK* ...))

What would be the effect on code generated by macros from another library? What if you use different macros of different libraries in the same form? Should code generated by a macro be all the same, or is code that is passed to a macro as a parameter handled differently?

Is this really worth the fuzz? Does this make the language easier to understand / more attractive to newbies?

But despite the fact that this change is easy and only good could come of it, it does not happen because there is no process by which this change can be effected (which is, I believe, a direct consequence of the fact that the realities of CL politics are that CL is utterly resistant to all change, though I would dearly love to be proven wrong on that).
The change you propose is easy to make, but the consequences of it are not necessarily easy to deal with.

I don't have the impression that the CL community is resistant to change.
Really? Then why has there been no change in CL in a decade?
I cannot judge the last decade because I have only entered the scene a few years before. But I have already noticed a lot of change in that short period of time.

Like what? Just writing code isn't the same thing as a change in the language.

We need a convincing example that would justify changing the language. (Like: Integrating the CLOS MOP.)

Peter Seibel has done a very good job of attracting newbies without any change to the language at all.

Just think how many more he might have attracted if he could have included an HTTP client as an example in his book.

Sooner or later, a more official process will emerge.

From your lips to God's ear.

I am a notorious optimist. You have to deal with this. ;)

See the various projects in various places that are quite healthy, as far as I can tell. (If I remember corretly, http://cl-user.net counts more than 600 entries.)
Non-sequitur. There is a big difference between writing code in the language and making changes to the language.
I strongly disagree. We can get quite far in Common Lisp, even for things that some people have considered to be only doable by changes to the language in the past. It's a good idea to explore the boundaries first.

You mean like http://www.flownet.com/gat/locales.pdf for example?

Yep. I think we can get even farther than that.

(Oh, and anyone who wishes to prove me wrong, please not that there is a big big difference between effecting change in CL and effecting change in an implementation of CL.)
Sure. But do note that the language constructs that are part of Common Lisp have been tried in other Lisp dialects before. I think that picking a single Common Lisp implementation and experimenting with language constructs there to see whether they pay off before proposing them as official features is the healthier approach.
Indeed. I'm not saying that we should dive wholesale into a redesign. All I'm saying is that there ought to be an end-game for the process.
...and this is exactly where the problem starts: The CLRFI process had the problem that it was overengineered, too bureaucratic, and since the people behind it didn't have the resources (mostly time) to really support it, it didn't get off the ground. The overengineering came, I think, from the fear that CLRFI submitters would go too far

Yes. "Fear of going too far" is a source of much of the resistance to change in the CL community.

I agree.

I repeat my slogan (in English this time): different is not necessarily better. But better is necessarily different.

However, it's also important what this should exactly mean, because it's also clear that not any different way will actually lead to an improvement.

and that's exactly an issue that a sanctioned process would have to deal with: where to draw the line between changes that go too far and changes that are ok. I mean, would a proposal to change Common Lisp into a Lisp-1 be acceptable? Addition of call/cc? Removal of LOOP and replacement with iterate? Removal of CLOS, to make the language smaller?

Deprecating NTH in favor of ELT?

That's all? ;)

(Note that my list was a list of examples that were actually discussed as part of the ANSI standardization process, if I understand correctly.)

IMO, just having the ability to (semi-)officially deprecate cruft, even if it never actually goes away, I think would have enormous payoffs. But we don't currently have that ability.
Some people think that the existing deprecations in ANSI Common Lisp should be removed...

And your point would be?

It's hard to get an agreement on these things, and it's hard to avoid making the language even more complex than it is. Here are two passages from the "The Evolution of Lisp" by Gabriel/Steele:

"Once there is a cleanup format for changes, there are a raft of changes made to Common Lisp. Hundreds of changes are made, many for no compelling reason."

"Though this might seem funny, it shows how a process of increasing desire for expressiveness, intensified attention to getting the details right (even for details that almost never matter), the need for individuals to make their mark, and a seemingly deliberate blind eye towards commercial realities can lead to an unintended result—a large, unwieldy language that few can completely understand."

In other words, the danger that the result could be even worse than what we currently have is a real one. This needs to be addressed.

BTW, we haven't even touched the question on how to evaluate whether the resulting language will actually be easier to understand by newbies or not. I guess that different people also have different ideas in this regard.

I have actually tried to design a more easily learned Lisp that could be embedded in CL and I keep running headlong into certain fundamental limitations, like the inability to intercept the handling of undeclared globals.

Why don't you write an interpreter first? That should be easier.

I think there are better examples than the ones you propose.
Of course there are. If you think that is relevant then you have completely missed the point.
It is relevant. It shows that the psychological strain isn't high enough, because even the better examples don't make Common Lispers say that installing a new sanctioned process should have a high priority.

Yes, that is clearly true. IMO it is lamentable.

Maybe, maybe not. It's how it is.


Pascal

--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
.

Relevant Pages

  • Re: How Common Lisp sucks
    ... in the Common Lisp community. ... libraries that work across implementations that provide de facto ... This is one of the very few instances of behavior outside the standard ... to the language at all. ...
    (comp.lang.lisp)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... but having third party libraries to support the new ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ...
    (comp.lang.lisp)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ... , I think that though libraries will be ...
    (comp.lang.lisp)
  • Re: Understanding # and function variables
    ... That's the reason for my statement that I don't care whether a ... >>change is standard compliant or not. ... >>substantial revision of ANSI Common Lisp and would provide equally ... I will find out about an already existing language that is strictly ...
    (comp.lang.lisp)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)