Hacker News new | past | comments | ask | show | jobs | submit login
Common Lisp: The Untold Story (2008) (nhplace.com)
70 points by daveloyall on May 27, 2016 | hide | past | favorite | 22 comments



Nice first person view of history that affected me.

Early on, Common Lisp was a bummer for me since my underpowered Xerox 1108 Lisp Machine ran very nicely with InterLisp, but was slow after the Common Lisp upgrade.

I came around to appreciating Common Lisp and the first book I wrote, that Springer-Verlag published, was a Common Lisp book.

Except for doing occasional consulting projects, mostly machine learning and NLP, I am mostly retired now. In retirement I have considered going full circle back to Common Lisp for my own personal research projects but I am unlikely to do that because there is so much code in Java, Python, etc. that I rely on.


I bought a copy of Portable GUI Development with C++ and always liked how clean most of the examples seemed. I was so disappointed to never find an actual cross-platform C++ library that lived up to the book. Was the code pulled from an existing library, or was it just example code of what could be?

Either way, thanks. Your book helped me get started in C++ and today I'm still working in C++ and liking it more than ever.


Thanks! I looked in my archives this morning and couldn't find the code for the book but I did find it on the Internet Archive (archive.org). I put the ancient ZIP file on my web site: http://markwatson.com/opencontentdata/GUI2ND.zip


I grabbed a copy, thank you.

Did you use the GUI library in any "real" projects?


I did but always in a very hacked up form. That library was limited, but maybe because it was my own code, it was easy to hack on. At work, I morphed just the XWindows part to what we ended up calling ULIB, and it allowed other programmers to write our application for the Navy without learning the details of X Windows. I would extend ULIB as needed, over the course of a year.


> I am unlikely to [go back to Common Lisp] because there is so much code in Java, Python, etc. that I rely on

I'm very late to this thread, but just wanted to suggest that you might explore using Armed Bear Common Lisp[1] to write CL that hooks into your existing Java projects / useful Java APIs, etc.

[1] https://common-lisp.net/project/armedbear/


I spent some time with your book (the neural networks section in particular) around Christmas/New Year (when Springer gave access to hundreds of books by mistake). Being able to run code written 25 years ago with only minor modifications is great.


Advantages of Common Lisp!

I am glad you got a copy of the book. I wish it would be released fro free permanently. Richard Stallman asked me about re-releasing this book under the GNU Documentation License, but I don't own the copyright.

Thanks for your comment.


That ISLISP phenomenon is curious. It seems that almost overnight, this counter-group whipped a Lisp dialect seemingly out of thin air, and got it ISO standardized.

I'm also curious about the role of Vince Manis in the whole thing, (because I knew him as an instructor at the University of British Columbia).

http://islisp.info/sponsors.html

"In addition to organizational support, we appreciate and acknowledge having received personal support from:

Vincent Manis"


ISLISP is indeed interesting, albeit more from a political standpoint than a technical one. It really was not an overnight process -- ISO had started the project shortly after the ANSI committee for Common Lisp was formed. There was fear in Europe and in Japan that the US would have too much control over the future of Lisp with only an ANSI standard and no international one. What ISLISP actually wound up being, after about a decade in development, is a crippled subset of Common Lisp, modulo alpha conversion (some things were renamed). Politically, it worked to assuage the fears over American control, but technically it was a flop. As far as I can tell, the only implementation currently available is OpenLisp from Eligis, which is commercial, expensive, and features many extensions to the standard language.

I have a hunch that the politics surrounding ISLISP also lead to the demise of EuLisp, which was a much more interesting language than ISLISP turned out to be. If ISLISP had been based on EuLisp rather than Common Lisp, I think it might not have fallen flat on its face the way it did, because it would have had something to offer beyond what Common Lisp offers.

On a related note, Kent Pitman, the guy who actually wrote the ANSI Common Lisp standard, also wrote the ISLISP standard. Of course, he was not the sole designer of either language, but he's the guy who put the design into words. If you're interested in knowing some more about ISLISP, he may be willing to give you some information. He's active on Twitter and comp.lang.lisp (Usenet).


By "modulo alpha conversion" I understand you to mean that the functionality was the same, only the names changed in some cases. A clearer way to put this would be to talk about "equivalence" or maybe even isomorphism?

I'm commenting because the notion of alpha conversion always seems like an inflated idea in the lambda calculus context. Of course \x.x means the same thing as \y.y, no need to make a song and dance about it...

Edit: to add a bit of value, here's Andrew Pitts on the subject:

"The tedious and error-prone nature of ad hoc solutions to this semantically trivial, but pragmatically non-trivial issue of α-equivalence is widely acknowledged"

https://www.cl.cam.ac.uk/~amp12/research/freshml/freshml-fin...

(He is talking about programming language support for actually doing metaprogramming jobs that involve preserving alpha equivalence.)


I disagree that talking about equivalence or isomorphism would be clearer, simply because those two terms are ambiguous. They each have multiple definitions, whereas, as far as I'm aware, alpha conversion only has one. You are correct in your interpretation.

I'm not making a song or a dance about alpha conversion, I'm simply using it for description because it is a well-defined notion with a precise meaning. I don't see the point in trying to come up with some other term that means the same thing, when a perfectly good term is already available.

Anyway, I appreciate that you are trying to be helpful, but I stand by my phrasing :)


I don't understand why ISLISP needed an update in 2007. Was the large and vibrant ISLISP world beginning to fragment due to vendors pulling in different directions?


Honestly, I don't understand why, either. To be honest, I'm not quite sure what the differences are between the 1997 edition and the 2007 edition, despite having read both. Perhaps if I were actually an ISLISP programmer, something would've jumped out at me, or if I had read them with the intent of doing comparison (which I may do, now that I think of it).

ISLISP's biggest weakness, in my opinion, is that it lacks a standard module system. Perhaps if they decide to do a 2017 update, modules will make it in there ;)


Standards organizations periodically insist on updates in order for a document to be considered active. This assures things don't decay but it can also be a way to churn business.

But also there are sometimes typos and other details to fix, noticed through use, which I thin was the case here (though I'd have to go back and look at records I don't have at my fingertips to be sure, so please don't hold me to that--these remarks are extemporaneous, written on a subway while traveling), and yes there is an ISLISP community even if not at the scale of the CL community. One of the effects of ISLISP was to legitimize various dialects of Lisp that did not want or need to be Common Lisp. By being ISLISP compliant, they have some degree of interchange capability with one another.

ANSI CL has things it could fix, but the problem is that you can't open the process for edits merely to fix those things. Any opening of it to small edits opens the floodgates for many kinds of changes, and it might destabilize it. (There is a strong analogy to be made with having a second constitutional convention for the US Constitution, by the way.)

SO opening for edits and improvements might seem benign, but understand that in order to have voting standing (something there is a HUGE rulebook to assure), you have to be a member. ANSI's claim of fairness, which is all that stands between its entire business model and an antitrust suit, relies on fairness. Normally, companies cannot collude, but standards are a deliberate mechanism to avoid that, and they rely on strict application of rules to achieve a constructive notion of fairness, since any intangible notion of fairness would be untestable.

But it's pretty high overhead to have membership. Certainly it's expensive for individuals to be members in ANSI and it's left to mostly whichever companies go, so although the intent is fairness, in my personal view it's very difficult to assure fairness exactly because of the rules that try to assure it. It's almost a catch-22. The very fact of the rules means people with should-be standing are locked out by cost, and so in practice all members who would want to be represented are not going to be, and the people making the decisions will be those who can afford membership.

In the international arena, where the members are countries, there are similar issues though only countries can be members. As discussed in Untold Story, there is a risk of single individuals in countries that don't really care about a standard getting the same vote as a country like the US that might care a lot (or vice versa, perhaps, for other standards--I apologize for the US-centric nature of that remark, but the problem is quite general and I just perceive and express it as a US issue when really it's the same for everyone rule-wise and it's the business world and/or wealth and/or activity that is unevenly divided).

In fact, I think the ISLISP world is pretty fairly administered and I don't think there was much debate about the 2007 update. It was smoothly and easily handled by Taiichi Yuasa. I did editorial work to help with that.


> One of the effects of ISLISP was to legitimize various dialects of Lisp that did not want or need to be Common Lisp. By being ISLISP compliant, they have some degree of interchange capability with one another.

Which dialects are those? As far as I can tell, the main non-CL influences recognized by the ISLISP spec (EuLisp, Le-Lisp, and Scheme) all pretty much ignored ISLISP entirely (except for perhaps EuLisp, which may or may not have been canceled to make way for ISLISP... I'm still investigating the history of that one... in any case, EuLisp was very different from ISLISP).

At this point in time, the only ISLISP implementation I can seem to find is OpenLisp from Eligis, who was previously a Le-Lisp vendor. Here and there, I've found references to about three other implementations, but they all seem to have been wiped off the Web and no longer exist.

On a tangent, EuLisp was absolutely beautiful, and it's a real shame that it was never finished. It also had some "new" things to offer the world of standardized Lisps, whereas ISLISP really doesn't offer anything that couldn't already be found in Common Lisp.


Dialects of Lisp that don't want to be Common Lisp probably also don't to be ISLISP even less.

If I'm a hacker with ideas about implementing Lisp, I'm not about to whip out ISLISP and conform to it as a starting point. I'm going to invent everything from scratch and kind of just borrow things here and there from other dialects.

Therefore, its existence has no bearing on legitimizing what I'm doing. In fact, the existence of yet one more standard that I'm not conforming to is only undermining my legitimacy. ("There are seventeen standards; why are you inventing something new? Must be not-invented-here syndrome!")


The work started in 1988. Early 90s WG16 decided to use a Japanese proposal for Lisp with a CLOS-like object system added. Much of the work came from France, Germany, UK, Japan and the US.


I've gotten the impression in the past that ISLISP was largely based on pre-existing work by Queinnec, but I don't have any proof.


I think it might be fair to say that Christian Queinnec's "Reasonable Lisp" had some influence on the ISLISP committee, but overall ISLISP as a language is very obviously intended to be "compatible" with Common Lisp, in the sense that an implementation could be conformant to both ISLISP and Common Lisp in a single "mode". In fact, Kent Pitman wrote an ISLISP "compatibility package" in Common Lisp in order to make sure it was do-able prior to the ratification of ISLISP. I.e., ISLISP can be implemented as a library for Common Lisp, without the need for a separate interpreter/translator.


The sponsors are sponsors of the site. I'm not an official charity, so it's not deductible, but I still accept donations from people who appreciate the site and want to defray the costs of hosting it. It's unrelated to the sponsorship of the activity itself. -kmp


Note well that my remarks here and on islisp.info are my personal remarks, and funding likewise. As discussed in Untold Story, we created a mechanism to do personal things disjoint from what ISO did. Hence islisp.ifo dispenses the public domain version of ISLISP and is in some legal and logical way disjoint from the ISLISP standards process, though with obvious and deliberate parallels. So it's not surprising this funding/sponsorship thing is confusing. When I get back from traveling, maybe I can clarify that on the islisp.info site, at least.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: