More on Lisp syntax, and language extensions

Following my recent post on the topic, I thought of one more thing that the syntax of Lisp allows you to do. Being homoiconic, and the fact that code manipulation is so simple (it’s all lists), layering on “language extensions” becomes possible. For example, if Betty Programmer realizes that OO is a great way to design and write code but that Lisp by itself doesn’t provide an OO facility (there are no “class” constructs, no inheritance etc.) – she doesn’t need to despair.

She can write code to add an OOP system to the language. Yes, this means Lisp really blurs the distinction between the language designer and the programmer. In other words, while it’s fairly obvious that Lisp is very well suited to writing DSLs, it is also possible to fundamentally extend the language as well – like adding an OO system, or pattern-matching, or logic-programming (ala Prolog).

Now, obviously, I’m not proficient enough yet to do anything of this sort. But, as I said before, it is my intention to learn 🙂

Lisp. A language where being meta is something worth thinking about.

3 thoughts on “More on Lisp syntax, and language extensions

  1. Hi Amit,

    I find a helpful way to think about macros is that they allow you to abstract over syntax. During the compile phase, the system needs to translate your code into some data structures that it can use to generate machine code, bytecode, or whatever target. The syntax of the language is like a contract between you and the compiler where the rules of what you need to say for it to understand a certain meaning are defined. In CL, a macro definition is a statement that causes certain syntactic structures, defined by you, to be translated into other syntactic structures.

    You mention OO systems; CLOS, the common lisp object system, is actually implemented in CL. You can develop your own alternate OO system that’s more like the Smalltalk model, or whatever you need, if you don’t want to use CLOS.

  2. Pascal’s article is a really good intro to how macros help. It’s the idea of “syntactic abstractions” that I think is the crux of the matter – languages like Ruby (while allowing you some level of meta-programming) don’t allow this kind of flexibility. I mean, think about – adding pattern-matching to Ruby…

    Thanks for the link, Steve.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s