Thursday, September 10, 2009

And now a word from our thponthor

We're at sea today, cruising the Alaskan Inside Passage so there's not much to report trip-wise. So I thought I'd take a vacation from the vacation to write about some geek stuff.

For the last few months I've been getting back into Lisp programming thanks to the advent of Clozure Common Lisp. CCL has actually been around for a long time, but only this year has it gotten stable enough to get real work done. But having reached that point, CCL now in my view kicks some serious tushie because of its excellent integration with both Linux and OS X, including Cocoa. (I'm told it also runs on Windows but I wouldn't know about that.)

A couple of years ago I sketched out a plan for attracting more people to Lisp. The plan was for a new Lisp-like language that I dubbed Ciel (pun intended). The "hook" for this new language was going to be a fundamental focus on abstract associative maps. I produced a rudimentary implementation in C++ using the Boehm GC and CLN for the numerical tower. It was only a few hundred LOC, but it was nonetheless fairly featureful. It was also hopelessly unreliable. It would run for a while and then dump core. And because most of the code was C++ code that was written by someone else, debugging it was pretty hopeless. Sometimes it seems that C++ was specifically designed to be hard to debug. So I ultimately abandoned the effort.

But now that CCL is available as a platform I'm taking up this effort again. The goal is to produce an integrated collection of a programming environment, libraries, and introductory text so that newcomers can download it all as a package and have it all Just Work. In this respect Ciel would be similar to other integration efforts, like Lisp in a Box and Peter Seibel's Practical Common Lisp but with one important difference: what the package will aim to teach is *not* Common Lisp, but Ciel, a new dialect of Lisp specifically designed to be user-friendly to non-Lisp programmers. Think of Ciel as a mental bridge between Python and "real" Lisp.

Specifically, the features that are going into Ciel in furtherance of this goal are:

1. Abstract associative maps as a fundamental data type. This was the basis of the original Ciel proposal, but will only be one component of the "new" Ciel effort. Associative maps are fundamental to a wide variety of programming tasks, but traditional presentations of Lisp encourage both confusion and premature optimization by teaching association lists to beginners. Association lists are very powerful, but they are too low-level for a modern introduction. Instead, associative maps should be taught (and should be made available) as an abstract type. Students should be taught to *use* associative maps *before* they are taught how to implement them.

2. Iteration using iterators rather than recursion. Again, recursion is very powerful, and to really understand programming you have to understand recursion. But newcomers should not be forced to wrap their brains around recursion before they can do anything interesting.

3. Lexicons instead of packages. I believe that lexicons (which are similar to Python modules) have a better "impedance match" to the non-Lisp mindset.

4. Various tweaks to cover-up aspects of Common Lisp's design that perennially confuse newcomers, including a new design for global variables, and seamlessly integrated infix syntax. I haven't written about that last one yet, but here's a sneak preview: the idea is to co-op an unused portion of the Lisp syntax space, the juxtaposition of a symbol name and a left paren with no intervening whitespace, e.g. f(x). There is a simple reader hack that allows f(x) to be *read* as (f x). Add an off-the-shelf infix parser and you can write, e.g. f(x+y) with no leading hash-sign character macro, which tends to be off-putting to newcomers. I've been experimenting with this idea for a few weeks now and it seems to work pretty well.

5. A single binding construct that subsumes LET, MULTIPLE-VALUE-BIND, and DESTRUCTURING-BIND for lexical bindings, and a separate binding construct for dynamic bindings. The conflation of lexical and dynamic bindings in Common Lisp is, again, a source of perennial confusion for newcomers, and the payoff in terms of being able to run legacy code from dynamically scoped dialects of Lisp is not worth that cost.

6. Support for ((...) ...) syntax so that you can write the Y combinator without FUNCALL being the most prominent visual feature of the code.

7. A comprehensive library including a complete web framework: a client, a server, interfaces to various databases, an HTML and form generation library, etc.

And last but not least...

8. A step-by-step text targeted towards new programmers. This text will be unique in that it will not take a top-down or bottom-up approach, but will instead be "middle-out". Because it starts with a comprehensive library, it can extend the knowledge of that library both upward (how to *use* the library) and downward (how the library is implemented) more or less simultaneously. The hope is that this approach will both attract newcomers (because it will let them do useful things quickly and easily) and convert them into "real" Lispers (because they can easily see how the features they are using are built in the underlying Common Lisp implementation).

A year ago I would have thought all this to be hopelessly overambitious. But I've been working on it for about six months now, and at my current rate of progress I think I have a good shot at getting it all done inside of a year.

5 comments:

  1. This sounds really interesting, Ron. As a Pythonista, the idea of a CL-alike that is dictionary-obsessed is definitely attractive.

    ReplyDelete
  2. If dictionaries are what turn you on you don't have to wait. The dictionary code is available now:

    http://flownet.com/ron/lisp/dictionary.lisp

    ReplyDelete
  3. How does this effort compare to Arc?

    ReplyDelete
  4. Usually, people who want to "improve" Common Lisp, don't really understand its strengths. So rather than designing something "better", they design something that is not of interest to the same community that is interested in CL.

    Or, the new language occupies a specialized niche (e.g. logic programming, or strong typing): good in its domain, but not a replacement for all that CL can do.

    But your proposal is much more subtle than that. You really seem to be just polishing off the rough edges. Basically keeping the bulk of CL, but making a design that prioritizes "clean" and "right", rather than legacy compatibility. (Despite that description, your design has little to do with Scheme.)

    I'm surprised to find myself intrigued. None of your ideas sound objectionable to me, and each seem to be useful minor improvements.

    I'm eager to see where it all leads!

    ReplyDelete
  5. > How does this effort compare to Arc?

    Arc is a thin layer on top of Scheme while Ciel is (or will be when/if it gets done) a thin layer on top of Common Lisp.

    > Usually, people who want to "improve" Common Lisp, don't really understand its strengths.

    That's true. But it's also true that those who criticize people who try to improve Common Lisp often don't really understand its weaknesses.

    > I'm eager to see where it all leads!

    That makes two of us :-)

    ReplyDelete