Daniel's Blog

edit

Lisp

Posted by Daniel Lyons Mon, 11 Sep 2006 22:46:50 GMT

For my forthcoming master work on programming languages, I’ve decided to disqualify Lisp as a functional programming language. I figure this is a pretty bold move, but I have two reasons for doing it:

1. I want to distinguish the Lisp/Scheme family and talk about it independently of the functional programming field, because I think macros are the central feature of Lisp and they are not seen in other functional programming languages, and
2. I want the distinguishing characteristic of a functional programming language to be something other than merely functions as first-class citizens, because that admits all sorts of languages that aren’t really functional programming languages into the fray (like Python).

I finally today think I may have found a worthy discriminating attribute: partial applications as curried function calls. For example, in OCaml this is perfectly legitimate code:

# let f x y = x + y;;
val f : int -> int -> int = <fun>
# f 2;;
- : int -> int = <fun>

f 2 returns a function which takes a single argument. That function adds two to its argument. It is identical to this code in OCaml:

(+) 2;;
- : int -> int = <fun>

In Lisp, you get this instead:

? (defun f (x y)
    (+ x y))
F
? (f 2)
> Error in process listener(1): Too few arguments in call to 
#<Compiled-function F #x83AD6AE>: 1 provided, at least 2 required. 

To achieve the same effect I’d have to go to all the trouble of creating a lambda and specifying the arguments.

This little difference I think will prove to be good enough to rend Lisp free of the functional programming shroud so I can talk about it completely separately.