Am Freitag, 16. September 2005 15:29 schrieb Glynn Clements:
David Roundy wrote:
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Lisp is impure, weakly typed and has way too many parentheses. Why would we use lisp? It seems to be lacking almost all the advantages of Haskell, and have an ugly, inflexible syntax to boot.
The ability to dynamically generate, manipulate and analyse code in a structured manner provides a flexibility which is unmatched by any other language I know of.
A good example is Emacs; lisp is entirely the right language for that, IMHO.
Could you explain this a bit more, please? To the moment, I cannot imagine cases where you need LISP's way of code analysis and manipulation because Haskell's capabilities are not sufficient. In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them. But you can use your do expressions etc. to construct action descriptions with a more general type like MonadIO m => m a. Then you can instantiate m with a monad whose values store part of the action's structure so that this information can be used later. Or you use a monad which doesn't keep structural information to use it for later processing but which does the processing upon construction. Best wishes, Wolfgang
Wolfgang Jeltsch wrote:
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Lisp is impure, weakly typed and has way too many parentheses. Why would we use lisp? It seems to be lacking almost all the advantages of Haskell, and have an ugly, inflexible syntax to boot.
The ability to dynamically generate, manipulate and analyse code in a structured manner provides a flexibility which is unmatched by any other language I know of.
A good example is Emacs; lisp is entirely the right language for that, IMHO.
Could you explain this a bit more, please? To the moment, I cannot imagine cases where you need LISP's way of code analysis and manipulation because Haskell's capabilities are not sufficient.
In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them.
And thus they are not data.
But you can use your do expressions etc. to construct action descriptions with a more general type like MonadIO m => m a. Then you can instantiate m with a monad whose values store part of the action's structure so that this information can be used later. Or you use a monad which doesn't keep structural information to use it for later processing but which does the processing upon construction.
Yeah, but this is heading in the direction of Greenspun's Tenth Rule of Programming: Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." You could easily end up doing the same thing in Haskell. The main thing about Lisp is that it tends to make it fairly easy to write something close to the ideal language for the task in hand without starting from the ground floor. You get stuck with Lisp's token syntax, and the semantics of its core primitives, but you can replace anything else. Every other language (including Haskell) tends to have the problem that eventually you will encounter a situation where the language's own worldview gets in the way. Or, to put it another way: if Haskell is so flexible, why do we need Template Haskell? I can't imagine a "Template Lisp"; it would just be Lisp. -- Glynn Clements <glynn@gclements.plus.com>
On Fri, Sep 16, 2005 at 05:40:04PM +0100, Glynn Clements wrote:
Every other language (including Haskell) tends to have the problem that eventually you will encounter a situation where the language's own worldview gets in the way.
Are you sure that lisp's worldview never gets in the way?
Or, to put it another way: if Haskell is so flexible, why do we need Template Haskell?
It's nice to have Template Haskell, but saying that we need it is a bit of an overstatement. In the GHC Survey 2005 only 9% of people said it's essential. Well, OK, I was one of them, but I think you know what I mean.
I can't imagine a "Template Lisp"; it would just be Lisp.
The power of lisp macros is often overrated. I remember a long discussion crossposted on comp.lang.lisp an comp.lang.functional. The lisp advocates gave examples for how macros allow to do things supposedly unavailable in other languages. Surprisingly, most of these things were equally easy to do with higher-order functions and closures in Haskell. I am sure that lisp gurus can achieve great things with macros, but I'm not sure they are the best tool for software engineering problems. I think they can make the code more difficult to understand, make the semantics less uniform (despite the uniform syntax), and can become an abused ugly hack. Don't get me wrong - I still think that lisp is one of the best programming languages around and from time to time I am trying to learn a bit of it. One of the things that puts me off is the attitude of its community - it seems to be very close minded. Best regards Tomasz
Date: Fri, 16 Sep 2005 23:33:46 +0200 From: Tomasz Zielonka <tomasz.zielonka@gmail.com>
On Fri, Sep 16, 2005 at 05:40:04PM +0100, Glynn Clements wrote:
Every other language (including Haskell) tends to have the problem that eventually you will encounter a situation where the language's own worldview gets in the way.
Are you sure that lisp's worldview never gets in the way?
Or, to put it another way: if Haskell is so flexible, why do we need Template Haskell?
It's nice to have Template Haskell, but saying that we need it is a bit of an overstatement. In the GHC Survey 2005 only 9% of people said it's essential. Well, OK, I was one of them, but I think you know what I mean.
I can't imagine a "Template Lisp"; it would just be Lisp.
The power of lisp macros is often overrated. I remember a long discussion crossposted on comp.lang.lisp an comp.lang.functional. The lisp advocates gave examples for how macros allow to do things supposedly unavailable in other languages. Surprisingly, most of these things were equally easy to do with higher-order functions and closures in Haskell.
But were they as efficient? The beauty of macros is that a lot of things can be done with no run-time overhead at all. Not that I'm taking a stand on the Haskell-vs-Lisp argument; I think everyone should learn both languages. Mike
On Fri, Sep 16, 2005 at 02:37:14PM -0700, Michael Vanier wrote:
But were they as efficient?
If some code is equivalent to macro expansion then the compiler should be able to optimize it to the same extent as a macro.
The beauty of macros is that a lot of things can be done with no run-time overhead at all.
Macros can lead to bigger generated code size, which can affect performance. Best regards Tomasz
Tomasz Zielonka wrote:
Every other language (including Haskell) tends to have the problem that eventually you will encounter a situation where the language's own worldview gets in the way.
Are you sure that lisp's worldview never gets in the way?
I wouldn't say never. But it's main advantage is that it doesn't really have much of a worldview. Its primary composite data type is the heterogeneous linked list, which is isomorphic to both binary trees and n-ary trees. This provides a reasonable fit for most common data structures, and also for most languages (anything defined by a recursive grammar can be represented as a parse tree). The complete absence of keywords is another useful feature (I've lost track of the various C packages which had to have identifiers named "class" renamed to allow for C++). Even "quote" is just another symbol. Ultimately, all languages are limited by their choice of primitives.
Or, to put it another way: if Haskell is so flexible, why do we need Template Haskell?
It's nice to have Template Haskell, but saying that we need it is a bit of an overstatement. In the GHC Survey 2005 only 9% of people said it's essential. Well, OK, I was one of them, but I think you know what I mean.
I can't imagine a "Template Lisp"; it would just be Lisp.
The power of lisp macros is often overrated. I remember a long discussion crossposted on comp.lang.lisp an comp.lang.functional. The lisp advocates gave examples for how macros allow to do things supposedly unavailable in other languages. Surprisingly, most of these things were equally easy to do with higher-order functions and closures in Haskell.
I am sure that lisp gurus can achieve great things with macros, but I'm not sure they are the best tool for software engineering problems. I think they can make the code more difficult to understand, make the semantics less uniform (despite the uniform syntax), and can become an abused ugly hack.
Well, this is heading towards the inevitable paradox (Gödel's theorem, halting problem, etc). If you allow the programmer to escape from your chosen semantic model, you no longer have the luxury of being able to assume those semantics. Ultimately, the issue isn't whether shooting oneself in the foot is a good idea, it's whether you leave it up to the language or to the programmer to prevent it. Both have their pros and cons. In that regard, Lisp and Haskell are almost opposite extremes, with more conventional languages inbetween. Haskell's safety and consistency can get in the way, while Lisp's freedom can be quite unsafe and inconsistent.
Don't get me wrong - I still think that lisp is one of the best programming languages around and from time to time I am trying to learn a bit of it. One of the things that puts me off is the attitude of its community - it seems to be very close minded.
Hmm. That depends upon which faction of the community you're dealing with. If you get into discussions about the merits of Lisp on public fora, you'll likely be dealing with the evangelists. Language evangelists are often closed-minded whatever the language. -- Glynn Clements <glynn@gclements.plus.com>
From: Glynn Clements [mailto:glynn@gclements.plus.com]
In that regard, Lisp and Haskell are almost opposite extremes, with more conventional languages inbetween. Haskell's safety and consistency can get in the way, while Lisp's freedom can be quite unsafe and inconsistent.
I disagree with your safety distinction. Haskell and Scheme are both extremely (and I believe, equally) safe ... (Common lisp does seem to offer lots of type holes). The key difference between Haskell and Scheme is that Haskell supplies more guidance earlier -- you can supply a (simple/limited) proof that your program doesn't go wrong, and have it checked in advance. Scheme offers no way to provide an advance proof, but it still checks at execution time. Chris Dutchyn Software Practices Lab cdutchyn@cs.ubc.ca
Hello Christopher, Saturday, September 17, 2005, 4:21:30 AM, you wrote: CD> Scheme offers no way to provide an advance proof, but it still checks at CD> execution time. ALL modern laguages check at least at execution time. but compile-time checking is much better, otherwise you need to check every execution path of program after each modification -- Best regards, Bulat mailto:bulatz@HotPOP.com
On Friday 16 September 2005 18:40, Glynn Clements wrote:
Wolfgang Jeltsch wrote:
In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them.
And thus they are not data.
Huh? I'd say they are not /concrete/ data, but (abstract) data they surely are(?) Ben
On Tue, Sep 20, 2005 at 12:25:00PM +0200, Benjamin Franksen wrote:
On Friday 16 September 2005 18:40, Glynn Clements wrote:
Wolfgang Jeltsch wrote:
In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them.
And thus they are not data.
Huh? I'd say they are not /concrete/ data, but (abstract) data they surely are(?)
and you are certainly free to turn them into concrete data by creating your own data type which you then can inspect and modify and then "interpret". John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham wrote:
In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them.
And thus they are not data.
Huh? I'd say they are not /concrete/ data, but (abstract) data they surely are(?)
and you are certainly free to turn them into concrete data by creating your own data type which you then can inspect and modify and then "interpret".
IOW, you are free to write a Lisp interpreter in Haskell. But it's a lot easier to do it in Lisp. That, in a nutshell, is Lisp's key strength. It uses the same structure for code as for data, which makes it very easy to add new language features. -- Glynn Clements <glynn@gclements.plus.com>
participants (8)
-
Benjamin Franksen -
Bulat Ziganshin -
Christopher Dutchyn -
Glynn Clements -
John Meacham -
Michael Vanier -
Tomasz Zielonka -
Wolfgang Jeltsch