3 ms·
Automatic currying: Haskell does it; Lisp doesn't. You can do partial evaluation in Lisp but it's not as convenient. This makes Haskell more functional than Lis
by dreamcompiler 7y ago
Automatic currying: Haskell does it; Lisp doesn't. You can do partial evaluation in Lisp but it's not as convenient. This makes Haskell more functional than Lisp and eliminates one use case (or maybe more) for macros.
Laziness: You can build infinite data in Lisp but again, it's not as convenient.
Monads: Possibly the most mind-bogglingly useful programming pattern I've explored in the last 20 years, and you can't completely build them in Lisp. You can get about 75% of the way toward monads in Lisp but that last 25% requires manual one-off coding because Lisp functions don't automatically know the types they return. Even using macros I haven't figured out a way to solve this problem.
- kazinator 7y agoOn the other hand, Lisp gives you variadic functions like (list) (list 1) (list 1 2 3 4). Lisp catches it in a straightforward way when you pass too many parameters to a non-variadic function, or fewer than the required number of parameters to any function. (cons 1) is a plain and simple error rather than a correct expression that evaluates to an unintended (lambda (x) (cons 1 x)) term. Macros can provide a clear explicit syntax for partial evaluation in which everything is visibly delimited, like (op cons 1).
- dreamcompiler 7y agoI think you're highlighting the downside of ubiquitous laziness. In a lazy world there's nothing wrong with (lambda (x) (cons 1 x)). But if you want to call this an error earlier, I agree that Lisp defaults in that direction.