Scheme Versus Common Lisp: Why?

Anyone new to Lisp will quickly find that among certain folks there is very much an “us versus them” mentality when it comes to Scheme and Common Lisp.
Is it just human nature that drives the mentality? Is it boredom?
Since Scheme and Common Lisp are both Lisp dialects, in some ways they are very similar; but in other ways they are quite different. The thing is that every language decision is a trade off from which we can learn. Most students of programming would look to both the similarities and differences in each language and recognize their function and beauty!
One thing that I can guarantee that you will notice pretty quickly once you start hanging around Lispers (in general) is that there is a noticeable difference in attitude and demeanor among folks that have studied and appreciate both Common Lisp and Scheme, and the folks that have not.
The folks that have studied and appreciate both languages are simply a much more pleasant group of people to be around. Perhaps that is how the expression about “the haves and the have nots” came to be?

Chicago Intro to Lisp Workshop

The first event held by the Chicago Lisp User Group will be an Intro to Lisp Workshop. It is

is a half-day workshop to introduce Lisp and its goodness to other programmers. The primary audience is the Chicago Linux User Group but it open to everyone. This is the initial announcement and tentative schedule.

Looks fun, even more-so if you present at it!

Lisp Changes How You Think

It is true what people say about Lisp, it changes how you think. In particular, it changes how you think about yourself!
If you pursue the “Road to Lisp”, it will serve as an elucidative experience as to whether or not you are “good” at programming. You see, I used to confuse “doing” with “learning”. All the “greats” tell you to learn a new language each year, but they don’t really tell you why, just that something good will happen. Now I can tell you from experience that I have had great fun and learned a lot jumping from language to language, but that strategy for learning is poor use of time and you’ll probably just end up being an average programmer in more languages after it is all said and done. There are better, much better ways to study the fundamentals of programming.
Lisp is one of those ways.

EuLisp

EuLisp

is a dialect of Lisp and as such owes much to the great body of work that has been done on language design in the name of Lisp over the last thirty years. The distinguishing features of EuLisp are (i) the integration of the classical Lisp type system and the object system into a single class hierarchy (ii) the complementary abstraction facilities provided by the class and the module mechanism (iii) support for concurrent execution.

Anaphoric Macros

Does the convenience that anaphoric macros provide justify breaking hygiene? In that chapter of On Lisp, the author stated that:

This chapter will show that variable capture can also be used constructively. There are some useful macros which couldn’t be written without it.

My evaluation of that claim is that while the former is true, anaphoric macros are not evidence of such a case as they only save you a variable binding. The latter claim is interesting because it begs the question of whether or not they should be written as macros at all. It made me wonder how anaphoric macros might look in Scheme, how they might look as functions, and whether one is clearly superior to the other.
Continue reading “Anaphoric Macros”

Lisp code is not a parse tree

One fact about Lisp is that its code can be visualized as a tree structure. Another fact is that syntactic extension (macros) can be applied to that code to change it. Taking both of those facts into account, it is very easy to assume due to the similarity between these features and a typical parser->compiler system that the Lisp code is in fact a parse tree. Lisp code, however, is not a parse tree.
Addendum 04/29/08:
Instead, Lisp’s “parse tree” is a plain old list. Lisp works by using macros to pattern match and perform transformations from s-expressions to s-expressions. It is simplistic, sensible, and very powerful. It takes human readable data structures, and, lets human manipulate them. It is wonderful.
By definition, though, since Lisp’s parse trees are lists, Lisp code is a parse tree, thus seemingly negating the claim in the title of this post. The trouble with making a statement like this is that “parse tree” implies the parse trees that the other %99.999 of languages use. “The rest of the bunch” uses parse trees that I suspect are not meant for human consumption or production.
In most programming languages, it is the parsers responsibility to transform the syntax (how the code looks to you) into a parse-tree (how the code looks to the compiler). This is by design.
Syntax for humans is what matters most in a programming language, and it is why we all fall in love with different languages. We get a syntax we love, and so does the compiler. The parser is the translator between the two worlds. Take this example in Java.
If you take a look at the Java 1.5 Antlr grammar you’ll see that if you want to declare a class it would map to the following in the parse tree (with details not critical to this example omitted):

  1. packageDeclaration
  2. typeDeclaration
  3. classBody

Just looking at this you probably have a pretty good feel both for how this would look in Java and how the Java source code would map to its parse tree counterpart:

package alt.p.b.n.j; <-- packageDeclaration
public class Gnumerical <-- typeDeclaration
{ ... } <-- classBody

The compiler, though, won't care about whatever syntax your use to write your code, it just expects a tree that adheres to some syntax defined by some grammar. You could define classes, then, in Java, Ruby, or Smalltalk syntax and ultimately produce a parse tree for the JVM. So suppose that Antlr were to take your Java and build a Lisp-style decorated parse tree for the compiler (which it does not do), it might look like this:

(class
  (package 'alt.p.b.n.j)
  (name 'Gnumerical)
  (body '(body goes here)))

The problem (or solution) with Lisp is that it at its core has virtually no syntax. Don't get me wrong, it does have syntax. Take "if" for example.
"if" must be be evaluated in a certain order. If it weren't, you could never check if a value was not null before applying it!
Beyond conditionals, though, there just isn't much syntax to Lisp. You don't have to take the code that the programmer writes and parse it according to the some grammar so that the compiler can understand it; you are writing in the language spoken by the compiler. So, by virtue of Lisp's syntax, or lack thereof, there really is no place for a parse tree as one might expect in any other language. Lisp's syntax is that of the compiler itself, virtually no translation is occurring.
Accordingly, Lisp is not a parse tree, it is a plain old list (s-expression).
In writing this addendum I realized that I had made a pretty poor post. I knew what I thought, but not why I thought it (I thought I did, but I was wrong). That is the ultimate sin for a developer.
Thanks, Geoff, for so graciously pointing that out to me. I am a truly lucky person to have so many people in my life be so kind to me in light of me "being human".

Liskell

Liskell

is a new syntax frontend for Haskell. Next to its syntax in the form of symbolic expressions — which is also known as Lisp — Liskell also features an extended meta-programming facility. Its aim is to get the best of both worlds: being pure and functional with type inference in the tradition of Haskell, while providing the simplicity and uniformity in its syntax that is necessary for meta-programming.

Lisp Flavoured Erlang

Lisp Flavoured Erlang

is a lisp syntax front-end to the Erlang compiler. Code produced with it is compatible with “normal” Erlang code.

The really big change with this release is that

LFE is now Lisp-2 like Common Lisp, i.e. functions and variables reside in different name spaces, instead being a Lisp-1 like Scheme where they reside in the same name space.

(via PLNews)