Earlier quoted context omitted.
In non-lazy languages you would need to implement laziness to manage composing functions and have good performance. An example being take 5 . filter ... If evaluation wasn't lazy you would run take 5, return the result to filter and so on.
In the languages I use (Scala, Ruby) it's already done, Rust is using iterators which are lazy too. None of those languages are "lazy" in Haskell sense.
A philosophical difference between Haskell and Lisp (2015)
31–40 of 181 posts
Re: A philosophical difference between Haskell and Lisp (2015)
#32I've noticed that these differing approaches lead to argument order being flipped sometimes.
https://wiki.call-cc.org/man/5/Module%20(chicken%20string)#s...
Because Chicken's `string-split` expects its delimiter to be optional, it wants a string first.
https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-T...
While Haskell's emphasis on composition means it's more logical for the constant parameter—the delimiter—to be provided first.
It's not a great example, but the first one I can think of. The difference is starker when the Lisp command has many more parameters than the Haskell one, with some of them being optional. When trying to write cute point-free code in Scheme, I found myself using `flip` too much for it to be fruitful.
Re: A philosophical difference between Haskell and Lisp (2015)
#33I dislike the lisp convention of remove-if, remove-if-not, etc. Filter and take isn't much better. The python convention is much nicer: [x for x in foo if x not in y] Turns out, this can be expressed in Lisp: (list x for x in foo if x not in y) I've implemented this into my fork of Lumen that runs on Python. https://github.com/shawwn/pymen It feels very nice to use: > (list x for x in (range 10) if (= (% x 2) 0)) """…
For those that didn't know, Haskell does of course have list comprehensions:
[x| x [c| x Re: A philosophical difference between Haskell and Lisp (2015)
#34This is interesting to read having worked with Clojure, but never Haskell or CL. I expected the Haskell examples to look alien and the CL to look familiar, but the idiomatic Clojure solutions to the examples are almost identical to the Haskell solutions. E.g. take 5 . filter (not . p) . drop 3 becomes (->> s (drop 3) (filter (complement p)) (take 5)) ; for some sequence s I think it is also true of Clojure that it st…
Is there something similar to (->>) in Haskell? Edit: corrected “—>”.
I think there are some pipe-like operators in the popular Lens library (and presumably others as well). However, writing Haskell, you quickly get used to everything being backwards.
Re: A philosophical difference between Haskell and Lisp (2015)
#35I've noticed that these differing approaches lead to argument order being flipped sometimes. https://wiki.call-cc.org/man/5/Module%20(chicken%20string)#s... Because Chicken's `string-split` expects its delimiter to be optional, it wants a string first. https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-T... While Haskell's emphasis on composition means it's more logical for the constant parameter—the delimite…
I hate when I have to do flip. Dislike reading it even more. I don't know what the solution is, other than using points..
Re: A philosophical difference between Haskell and Lisp (2015)
#36Earlier quoted context omitted.
The article elaborates on this point a bit: > Like pipes in UNIX, the functions are clever enough to be performant when composed together–we don’t traverse the whole list and generate a new list each time, each item is generated on demand. In fact, due to stream fusion, the code will be compiled into one fast loop. I imagine it is hard to do the same optimization in a non-lazy language.
It's interesting that he says you also need purity to do the optimization, but Unix pipes are not necessarily pure.
Unix pipes don't do stream fusion, which is the optimisation to which he was referring.
Re: A philosophical difference between Haskell and Lisp (2015)
#37Re: A philosophical difference between Haskell and Lisp (2015)
#38This is interesting to read having worked with Clojure, but never Haskell or CL. I expected the Haskell examples to look alien and the CL to look familiar, but the idiomatic Clojure solutions to the examples are almost identical to the Haskell solutions. E.g. take 5 . filter (not . p) . drop 3 becomes (->> s (drop 3) (filter (complement p)) (take 5)) ; for some sequence s I think it is also true of Clojure that it st…
Is there something similar to (->>) in Haskell? Edit: corrected “—>”.
Is this what you're looking for? (&) http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-F...
Re: A philosophical difference between Haskell and Lisp (2015)
#39There is a strange... kind of poetry with Haskell. It is like math on wheels, math applied to procedures, math with... time. Its appeal to me is like the appeal of math to me, not like real analysis math but abstract algebra math. The beauty, the purity of mathematics of younger days that once became lost after encountering the sad complexities of the world. Understanding every little aspect and being able to prove e…
I followed a (pure) mathematics education, and I totally dig lisp. On the other hand, I abhor haskell and hate almost everything about it!
Re: A philosophical difference between Haskell and Lisp (2015)
#40Earlier quoted context omitted.
It's interesting that he says you also need purity to do the optimization, but Unix pipes are not necessarily pure.
Unix pipes don't do stream fusion, which is the optimisation to which he was referring.
So if I put (x1, x2...) through pipes f and g, instead of calculating all the f(x)s first followed by all the g(f(x))s, it calculates g(f(x1)), then g(f(x2)), etc.
How is that order of operations different to stream fusion? Why does stream fusion require more purity than Unix pipes?