4 ms·

> I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell. The easiest answer to that is, there's no syntax, which m

> I found the syntax very obtuse and it was not obvious why Lisp would be more powerful than Haskell. The easiest answer to that is, there's no syntax, which makes reimplementing your own Lisp parser trivial (one single function call, in fact). This in turn makes reimplementing your own Lisp, inline in Lisp, similarly trivial. That sounds like something out of an SICP exercise - and it is - but the same properties make it easier to reason about your code in a way that's far more abstract than other languages let you. Once you start treating your code as data that other parts of your code can manipulate, you can start refactoring in ways that simply aren't possible in other languages. This explanation by a well-known Perl programmer explains it very well: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... Another way I've heard it (this may have been pg, but I can't remember), is that, when writing idiomatic Lisp, you first think, "What language would make solving this problem really easy?" and then proceed to implement that language.

egonk 14y ago
Have you got a good example where Lisp macros would work but standard Haskell would "fail"? I've done some compiler work in Haskell like writing programs (semantic actions) as algebraic data structures and then transforming or interpreting the tree. Would I gain something by using Lisp macros in this instance?
- tome 14y ago
  Many of Lisp's uses of macros can be replicated in Haskell by taking advantange of lazy evaluation. This is enough for most needs I've ever had, but some things still need the macro system that Template Haskell provides. Deriving lenses from type declarations is one of the up-to-the minute uses.
- kd0amg 14y ago
  Have you got a good example where Lisp macros would work but standard Haskell would "fail"? http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01539.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
draegtun 14y ago
If pg then perhaps it was (or stems from) this: Programming Bottom-Up - http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html
- chimeracoder 14y ago
  > In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. As you're writing a program you may think "I wish Lisp had such-and-such an operator." So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. That's close, but not quite the wording I remember, so I must have seen it somewhere else as well. That's a pretty good description of what I was referring to, though.
  - draegtun 14y ago
    I was (re-)reading On Lisp yesterday and came across two further variations by pg: In preface: As well as writing their programs down toward the language, experienced Lisp programmers build the language up toward their programs. Then later in 1.2 "Programming Bottom-up", pg rephrases that statement: In Lisp, you don’t just write your program down toward the language, you also build the language up toward your program

egonk 14y ago

Have you got a good example where Lisp macros would work but standard Haskell would "fail"? I've done some compiler work in Haskell like writing programs (semantic actions) as algebraic data structures and then transforming or interpreting the tree. Would I gain something by using Lisp macros in this instance?

tome 14y ago
Many of Lisp's uses of macros can be replicated in Haskell by taking advantange of lazy evaluation. This is enough for most needs I've ever had, but some things still need the macro system that Template Haskell provides. Deriving lenses from type declarations is one of the up-to-the minute uses.
kd0amg 14y ago
Have you got a good example where Lisp macros would work but standard Haskell would "fail"? http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01539.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

draegtun 14y ago

If pg then perhaps it was (or stems from) this: Programming Bottom-Up - http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html

chimeracoder 14y ago
> In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. As you're writing a program you may think "I wish Lisp had such-and-such an operator." So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. That's close, but not quite the wording I remember, so I must have seen it somewhere else as well. That's a pretty good description of what I was referring to, though.
- draegtun 14y ago
  I was (re-)reading On Lisp yesterday and came across two further variations by pg: In preface: As well as writing their programs down toward the language, experienced Lisp programmers build the language up toward their programs. Then later in 1.2 "Programming Bottom-up", pg rephrases that statement: In Lisp, you don’t just write your program down toward the language, you also build the language up toward your program