. . .

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 bill.wood@acm.org

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

"David F. Place" 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

"Tomasz Zielonka" writes:

On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote:

...

"David F. Place" 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

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:d@vidplace.com

On Sep 21, 2005, at 10:58 AM, Immanuel Litzroth wrote:

I personally find loop usually the most concise way to express my iteration requirements.

Perhaps, but with tail recursion equivalent to iteration you no longer have any real "requirement" to iterate. It's a lifestyle choice. :-) -------------------------------- David F. Place mailto:d@vidplace.com