4 ms·

I suppose, and I'm a big Purescript & Haskell fan these days but... My take is that Common Lisp was never really truly a functional language. It has always bee

I suppose, and I'm a big Purescript & Haskell fan these days but... My take is that Common Lisp was never really truly a functional language. It has always been a hybrid language that focused on the unique aspects of Lisp first, and everything else second. Lisp's focus on superior macro facilities, the CLOS, and the MOP really shows in the spec. CL primitives were never as concerned about general composability as they were about offering syntax to cover every conceivable case. To some extent, I miss this philosophy. Meta-syntactic programming is something important and fundamental to language (as opposed to the monadic style of haskell which is more fundamental to computation).

lispm 9y ago
> My take is that Common Lisp was never really truly a functional language. That's not really news. Lisp was always trying to support functional programming, but it was not enforcing it - though in some parts of the language non-pure functional programming is slightly difficult to avoid. What Common Lisp did first in Lisp was that it took the lexical binding first/always idea, explored in Scheme, and integrated it into Lisp. Different from Scheme, Common Lisp kept the support for dynamic binding directly in the language and still made use of it in the language. Closures already existed in the precursors of Common Lisp, but as a separate construct (see for example the support in Lisp Machine Lisp). Common Lisp also defined that lexical binding had to work both for the interpreter and the compiler - whereas in precursors of Common Lisp the Interpreter usually implemented dynamic binding by default and the compiler implemented lexical binding. Scheme in its standard did not mention compilation/interpretation and their effects - though it was expected that both, interpreters and compilers, use the same semantics. What Common Lisp does, both in the language and in its library, is to support a form of programming with functions, first class functions, higher-order functions. Implementations also support TCO, which enables a more functional style of control flow. Libraries then explore lazy streams (see for example the chapter on Series in CLtL2 from 1990) and similar concepts. Common Lisp was always a hybrid language supporting multiple paradigms out-of-the-box: symbolic programming, imperative/procedural programming, meta-syntactic programming, reflective programming, object-oriented programming, non-pure functional programming, meta-object-oriented programming. More complete implementations/applications add various forms of logic programming, rule-based programming, concurrent/parallel programming, visual-programming, ... The
- KirinDave 9y ago
  Since I have little to no patience today, I cannot resist saying: I have no idea why you said this, who you said it to, who you thought would find it compelling, or what it's point is. I know a lot of what you're saying, but you presented it in a contrarian mode. Like you were trying to make something clear. But your post doesn't illuminate anything except perhaps some trivia acquired in our shared history. My only conclusion is that you were eager to talk about this but not to have a conversation about it. Perhaps in the future, placing it higher up the comment hierarchy will get you want you want.
- deleted 9y ago
  [deleted]
dragonwriter 9y ago
> My take is that Common Lisp was never really truly a functional language. Lisps in general have always been what now is sometimes called "impure functional programming languages"; until fairly recently, it wasn't really all that common to equate pure functional languages with "real" functional languages, it seems to me that is used to be that a "real functional language" was one that had reasonable ergonomic support for programming in the functional paradigm, not one that supported only the functional paradigm.
kazinator 9y ago
Common Lisp was never really truly a functional language What tipped you off? Was it setq, or perhaps nconc or delete? For me, it was tagbody. I was like, "go ? Okay, this is still a functional language, but now way can I call it truly functional."
- lispm 9y ago
  Very funny. Thanks. I had to smile.
- KirinDave 9y ago
  People have decided to conflate "functional" with "purity" in an odd way in this thread. Is OCaml now not functional? I will leave discourse about the degree of purity that grants a "truly" moniker to people with more free time, but I suspect it's counter-productive.

lispm 9y ago

> My take is that Common Lisp was never really truly a functional language. That's not really news. Lisp was always trying to support functional programming, but it was not enforcing it - though in some parts of the language non-pure functional programming is slightly difficult to avoid. What Common Lisp did first in Lisp was that it took the lexical binding first/always idea, explored in Scheme, and integrated it into Lisp. Different from Scheme, Common Lisp kept the support for dynamic binding directly in the language and still made use of it in the language. Closures already existed in the precursors of Common Lisp, but as a separate construct (see for example the support in Lisp Machine Lisp). Common Lisp also defined that lexical binding had to work both for the interpreter and the compiler - whereas in precursors of Common Lisp the Interpreter usually implemented dynamic binding by default and the compiler implemented lexical binding. Scheme in its standard did not mention compilation/interpretation and their effects - though it was expected that both, interpreters and compilers, use the same semantics. What Common Lisp does, both in the language and in its library, is to support a form of programming with functions, first class functions, higher-order functions. Implementations also support TCO, which enables a more functional style of control flow. Libraries then explore lazy streams (see for example the chapter on Series in CLtL2 from 1990) and similar concepts. Common Lisp was always a hybrid language supporting multiple paradigms out-of-the-box: symbolic programming, imperative/procedural programming, meta-syntactic programming, reflective programming, object-oriented programming, non-pure functional programming, meta-object-oriented programming. More complete implementations/applications add various forms of logic programming, rule-based programming, concurrent/parallel programming, visual-programming, ... The

KirinDave 9y ago
Since I have little to no patience today, I cannot resist saying: I have no idea why you said this, who you said it to, who you thought would find it compelling, or what it's point is. I know a lot of what you're saying, but you presented it in a contrarian mode. Like you were trying to make something clear. But your post doesn't illuminate anything except perhaps some trivia acquired in our shared history. My only conclusion is that you were eager to talk about this but not to have a conversation about it. Perhaps in the future, placing it higher up the comment hierarchy will get you want you want.
deleted 9y ago
[deleted]

dragonwriter 9y ago

> My take is that Common Lisp was never really truly a functional language. Lisps in general have always been what now is sometimes called "impure functional programming languages"; until fairly recently, it wasn't really all that common to equate pure functional languages with "real" functional languages, it seems to me that is used to be that a "real functional language" was one that had reasonable ergonomic support for programming in the functional paradigm, not one that supported only the functional paradigm.

kazinator 9y ago

Common Lisp was never really truly a functional language What tipped you off? Was it setq, or perhaps nconc or delete? For me, it was tagbody. I was like, "go ? Okay, this is still a functional language, but now way can I call it truly functional."

lispm 9y ago
Very funny. Thanks. I had to smile.
KirinDave 9y ago
People have decided to conflate "functional" with "purity" in an odd way in this thread. Is OCaml now not functional? I will leave discourse about the degree of purity that grants a "truly" moniker to people with more free time, but I suspect it's counter-productive.