info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Meta-Circular Adventures in Functional Abstraction - Challenging Idiomatic Functional Programming in Common Lisp
32 views
Skip to first unread message
Chris Kohlhepp
May 12, 2014, 5:50:56 PM5/12/14
to
http://chriskohlhepp.wordpress.com/metacircular-adventures-in-functional-abstraction-challenging-clojure-in-common-lisp/
Clojure is a dialect of the Lisp programming language created by Rich Hickey. According to Wikipedia, Mr. Hickey created Clojure "because he wanted a modern Lisp for functional programming, symbiotic with the established Java platform, and designed for concurrency." Since then, Clojure has gathered somewhat of a following in the functional programming community, the other chief contender for functional programming on the JVM being the Scala programming language.
This blog will attempt to document my quest to achieve two of Mr. Hickey's goals using straight-up Common Lisp: idiomatic functional programming & concurrency. Why am I doing this? I tried Clojure and was disheartened by two aspects of the language: lackluster performance and the constant resurfacing of the Java and the JVM in error messages and other aspects of working with Clojure. I know of ClojureScript and the ability to run it on Google V8, but I suppose I really wanted a non-hosted language where I can intuitively map abstractions to assembler code by calling something like (disassemble ... ) on a simple function. I tried Scala and missed homoiconic macros. Somehow I could not shake the feeling that homoiconic macros were intimately tied to the very essence of functional programming. I was also puzzled by the suggestion that Lisp, in its current form, somehow lacked modernity. Popularity, yes, modernity I wasn't sure of...
We will add one twist to the story. With Lisp being a programmable programming language, I can surely re-engineer any design goals of Clojure using Common Lisp by way of macros -- but the challenge here is to do without such an effort. Therefore there are two rules in this game:
1) I am not allowed to write the keyword "defmacro"
2) I must rely on stock libraries / frameworks. "Stock" will be defined as installable via Common Lisp's package manager Quicklisp.
The "long and short of it is" that I want the utility of Clojure with the performance of Common Lisp. As Dough Hoyte points out in the book Let Over Lambda [Let-Over-Lambda], Lisp is not precisely a functional programming language, not in the the sense that Haskell and ML are functional programming language. I aim to challenge that
Clojure is a dialect of the Lisp programming language created by Rich Hickey. According to Wikipedia, Mr. Hickey created Clojure "because he wanted a modern Lisp for functional programming, symbiotic with the established Java platform, and designed for concurrency." Since then, Clojure has gathered somewhat of a following in the functional programming community, the other chief contender for functional programming on the JVM being the Scala programming language.
This blog will attempt to document my quest to achieve two of Mr. Hickey's goals using straight-up Common Lisp: idiomatic functional programming & concurrency. Why am I doing this? I tried Clojure and was disheartened by two aspects of the language: lackluster performance and the constant resurfacing of the Java and the JVM in error messages and other aspects of working with Clojure. I know of ClojureScript and the ability to run it on Google V8, but I suppose I really wanted a non-hosted language where I can intuitively map abstractions to assembler code by calling something like (disassemble ... ) on a simple function. I tried Scala and missed homoiconic macros. Somehow I could not shake the feeling that homoiconic macros were intimately tied to the very essence of functional programming. I was also puzzled by the suggestion that Lisp, in its current form, somehow lacked modernity. Popularity, yes, modernity I wasn't sure of...
We will add one twist to the story. With Lisp being a programmable programming language, I can surely re-engineer any design goals of Clojure using Common Lisp by way of macros -- but the challenge here is to do without such an effort. Therefore there are two rules in this game:
1) I am not allowed to write the keyword "defmacro"
2) I must rely on stock libraries / frameworks. "Stock" will be defined as installable via Common Lisp's package manager Quicklisp.
The "long and short of it is" that I want the utility of Clojure with the performance of Common Lisp. As Dough Hoyte points out in the book Let Over Lambda [Let-Over-Lambda], Lisp is not precisely a functional programming language, not in the the sense that Haskell and ML are functional programming language. I aim to challenge that
0 new messages