Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
David F. Place [EMAIL PROTECTED] writes: I was hoping that the examples I requested would be examples of particular control constructs or extensions to the language's syntax and semantics. Though I admit that such things are possible in lisp, I suspect that their utility is minimal. Ever heard of the loop macro? Immanuel Litzroth ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote: David F. Place [EMAIL PROTECTED] writes: I was hoping that the examples I requested would be examples of particular control constructs or extensions to the language's syntax and semantics. Though I admit that such things are possible in lisp, I suspect that their utility is minimal. Ever heard of the loop macro? Immanuel Litzroth I would be nice if you could give some examples for use of LOOP macro that you think would be cumbersome to translate to Haskell. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote: David F. Place [EMAIL PROTECTED] writes: I was hoping that the examples I requested would be examples of particular control constructs or extensions to the language's syntax and semantics. Though I admit that such things are possible in lisp, I suspect that their utility is minimal. Ever heard of the loop macro? Immanuel Litzroth I would be nice if you could give some examples for use of LOOP macro that you think would be cumbersome to translate to Haskell. That was not the original question and I think that would lead to pointless discussion about the meaning of cumbersome. Loop is an example of a control construct that can be implemented by a macro. One can can discuss it's utility, but it was deemed important enough to be standardized (by lisp people). It was only one of the macros developed at that time to do things sequencelike things (series, generators/gatherers were others) . Another example is UFFI, basically a bunch of macros to do platform independent foreign function interfaces. I a currently writing a macro to generate the functions and datastructures to read an ipod database. This allows me to declaratively say (defheader (header-name inherits-from) (field-name length optional reader)...). I doubt this would be easy in Haskell (maybe with TH it could be done) since I build a list of (header-name . (field-names ...)) at compile time which is then used to generate code that locally binds these to the result of reading them so that readers can refer to fields already read e.g. (let* ((field-name (reader stream))) ((field-name2 (reader field-name1 stream)) Immanuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
David F. Place wrote: I don't deny that all of the things you mentioned are wonderful indeed. I just wonder if they really could only be done in lisp or even most conveniently. Obviously, if you can do it in Lisp, you can do it in any Turing-complete language; in the worst case, you just write a Lisp interpreter. As for convenience: syntax matters. The equivalence of code and data in Lisp lets you write your own syntactic sugar. You're still bound by the lexical (token-level) grammar, although reader macros mean that isn't much of a restriction. -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Sep 21, 2005, at 3:53 AM, Immanuel Litzroth wrote: Ever heard of the loop macro? Yes, the loop macro is a good example for the argument against lisp. Lisp has features to support iteration that date back to the time before it was understood that tail recursion is equivalent to iteration. In fact, even in the early '90s most common lisp compilers didn't implement tail-merging. I doubt there is any program implemented using the loop macro that couldn't be more elegantly implemented recursively. In fact, when writing in lisp or scheme, I always write recursively now that I can depend on compilers to tail- merge. David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
David F. Place [EMAIL PROTECTED] writes: On Sep 21, 2005, at 3:53 AM, Immanuel Litzroth wrote: Ever heard of the loop macro? Yes, the loop macro is a good example for the argument against lisp. Lisp has features to support iteration that date back to the time before it was understood that tail recursion is equivalent to iteration. In fact, even in the early '90s most common lisp compilers didn't implement tail-merging. I doubt there is any program implemented using the loop macro that couldn't be more elegantly implemented recursively. In fact, when writing in lisp or scheme, I always write recursively now that I can depend on compilers to tail- merge. I personally find loop usually the most concise way to express my iteration requirements. Immanuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Wed, Sep 21, 2005 at 12:12:16PM +0100, Immanuel Litzroth wrote: Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote: David F. Place [EMAIL PROTECTED] writes: I was hoping that the examples I requested would be examples of particular control constructs or extensions to the language's syntax and semantics. Though I admit that such things are possible in lisp, I suspect that their utility is minimal. Ever heard of the loop macro? Immanuel Litzroth I would be nice if you could give some examples for use of LOOP macro that you think would be cumbersome to translate to Haskell. That was not the original question and I think that would lead to pointless discussion about the meaning of cumbersome. You are right, sorry. I agree that the ability to create your own control structures is a win. I only argue that when it's possible, it's better to avoid using macros for this. Another example is UFFI, basically a bunch of macros to do platform independent foreign function interfaces. Good example - laziness, HOFs and closures don't help much here. I a currently writing a macro to generate the functions and datastructures to read an ipod database. This allows me to declaratively say (defheader (header-name inherits-from) (field-name length optional reader)...). I doubt this would be easy in Haskell (maybe with TH it could be done) I am doing similar things with Haskell. The amount of TH code needed is minimal, I prefer to put most of the machinery in the type system. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Sep 20, 2005, at 3:43 PM, Glynn Clements wrote: 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. I assume that you refer to `eval' and the fact it operates on conses and symbols. Beyond the extremely contrived example of a metacircular interpreter, what are some examples of the benefits of this feature of lisp? What are some examples of language features that are easy to add? David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
David F. Place wrote: 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. I assume that you refer to `eval' and the fact it operates on conses and symbols. Beyond the extremely contrived example of a metacircular interpreter, what are some examples of the benefits of this feature of lisp? What are some examples of language features that are easy to add? Well, to state the obvious, being able to extend or replace the language's syntax and semantics. In particular, being able to do so locally. Probably the most useful consequence is the ability to create new control constructs without being constrained by the existing syntax and semantics (and without having to write your own monadic versions of existing functions). -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
I was hoping that the examples I requested would be examples of particular control constructs or extensions to the language's syntax and semantics. Though I admit that such things are possible in lisp, I suspect that their utility is minimal. On Sep 20, 2005, at 4:55 PM, Glynn Clements wrote: Well, to state the obvious, being able to extend or replace the language's syntax and semantics. In particular, being able to do so locally. Probably the most useful consequence is the ability to create new control constructs without being constrained by the existing syntax and semantics (and without having to write your own monadic versions of existing functions). David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
. . . I was hoping that the examples I requested would be examples of particular control constructs or extensions to the language's syntax and semantics. Though I admit that such things are possible in lisp, I suspect that their utility is minimal. As to utility, quite the contrary, I think. Offhand I can think of the screamer package for Common Lisp, which provides non-deterministic mechanisms for use in backtracking applications. For a while in the 80's there was practically a cottage industry implementing various flavors of Prolog and other Logic Programming languages in Lisp; one notable example was LogLisp. I think many of the more advanced constructs in CL were originally macro extensions to the earlier lisps; e.g. structures, objects and classes, the LOOP macro, streams and iterators, generalized setters and getters. Actors, which was one of the ancestors of OOP, was first as a Lisp extension. In the AI hayday of the mid-80's most of the expert system shells, providing forward and backward chaining mechanisms, frames and semantic nets, and object-centered and data-driven programming, were originally implemented as packages integrated into Lisp. All of these made non-trivial extensions to Lisp, and all were of arguably great utility. -- Bill Wood [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
I don't deny that all of the things you mentioned are wonderful indeed. I just wonder if they really could only be done in lisp or even most conveniently. Many years ago I read a paper by Phil Wadler about logic programing using a functional language. I think it was called something like How to replace failure with a list of successes. (Great title!) It blew my mind and made me doubt very much that the metaprogramming aspect of lisp had anything over clever functional programming. Oh -- speaking of control structures -- once you start passing around continuations you can do anything. Lisp has no advantage there. On Sep 20, 2005, at 5:45 PM, Bill Wood wrote: All of these made non-trivial extensions to Lisp, and all were of arguably great utility. David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
Bill Wood wrote: As to utility, quite the contrary, I think. Offhand I can think of the screamer package for Common Lisp, which provides non-deterministic mechanisms for use in backtracking applications. For a while in the 80's there was practically a cottage industry implementing various flavors of Prolog and other Logic Programming languages in Lisp; one notable example was LogLisp. I think the goal was to present an application where Lisp macros made for a more succinct program than the equivalent Haskell version. http://www.google.com/search?q=backtracking+monad Greg Buchholz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
Am Freitag, 16. September 2005 16:46 schrieben Sie: . . . 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. But, isn't this like saying that Java or C++ supports first-class function types because you can define a class with one method, the function of interest, and then create, pass, and return instances of the class? Yeah, you can do that, but it's awfully clumsy. But I could imagine that doing what I described in Haskell is not awfully clumsy. In fact, I don't like the idea of dealing with code at run-time, except when it is absolutely necessary. Also, it seems to me that the heart of Haskell is functional, not imperative. Can you create function definitions from data and evaluate them at runtime? Of course! Just define a function which takes an expression as an argument and returns the corresponding function, i.e., some kind of function parser. [...] -- Bill Wood [EMAIL PROTECTED] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
Am Freitag, 16. September 2005 18:40 schrieben Sie: 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. They are some kind of opaque 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. I'm not sure. Haskell is much more powerful than C, for instance concerning the type system. The point of the concept I described above is that the general MonadIO-based description of actions is very similar to what you would normally write when using IO directly. I doubt that you can do something similar with C. [...] 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. Haskell alone is not so flexible but Haskell with Template Haskell is. The difference is that the Haskell/Template Haskell combination separates compile-time evaluation/code generation clearly from runtime evaluation which is, in my opinion, a very good thing. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Fri, Sep 16, 2005 at 06:56:10PM -0400, David F. Place wrote: On Sep 16, 2005, at 6:26 PM, Glynn Clements wrote: Haskell's safety and consistency can get in the way, while Lisp's freedom can be quite unsafe and inconsistent. and lazy evaluation eliminates 99% of the need for macros in lisp. I wrote: supposedly unavailable in other languages. Surprisingly, most of these things were equally easy to do with higher-order functions and closures in Haskell. ... and laziness of course, and some other features too. Did I say equally easy? It is often easier. Creating your own control structures in Haskell is a pure pleasure. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Sep 16, 2005, at 6:26 PM, Glynn Clements wrote: Haskell's safety and consistency can get in the way, while Lisp's freedom can be quite unsafe and inconsistent. I have many years of experience designing and implementing commercial software in lisp and I strongly agree with the second part of this sentence. However, my more recent experience with Haskell makes me doubt very much the first part. Haskell's powerful type system hasn't in the least cramped my style and lazy evaluation eliminates 99% of the need for macros in lisp. (The other 1% is syntactic sugar of doubtful utility.) Since Haskell supports recursive polymorphic types it can easily handle all of the metaprogramming problems where lisp first made its mark. I don't see any reason to continue to use lisp. ps. This thread was on Haskell-cafe which seems more appropriate, so I'm bringing it back. David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
