Re:A difference between Haskell and Common Lisp
by adrusi on Monday December 21, 2015 @09:58AM
(#10771312)
Clojure, and to a slightly lesser extent scheme, are much more Haskell-like than common lisp or emacs lisp.
Clojure of course has pattern matching and lazy sequences, so naturally for collections it is very compatible with Haskell's philosophy.
Re:A difference between Haskell and Common Lisp
by galfarragem on Monday December 21, 2015 @09:37AM
(#10771209)
My first contact with programming (besides BASIC) was (auto)lisp. It was kind of a first love: every language I tried after Lisp was a disappointment. Then I found Haskell..
Re:A difference between Haskell and Common Lisp
by galfarragem on Monday December 21, 2015 @10:01AM
(#10771327)
A bit off topic: interesting link with project euler solutions written in haskell and clojure (and sometimes other languages). With execution time log.
Re:A difference between Haskell and Common Lisp
by catnaroek on Monday December 21, 2015 @09:37AM
(#10771205)
Minor nitpick. Technically, this:
#(->> % (drop 3) (filter p) (take 5))
Is equivalent to: take 5 . filter p . drop 3
Re:A difference between Haskell and Common Lisp
by takle on Monday December 21, 2015 @10:04AM
(#10771344)
One could also change the Haskell. Data.Function (&);
Control.Arrow (>>>)
-- the pipe operator seems to be all the rage these days
(|>) = (&)
-- forward application + forward composition
xs |> (drop 3 >>> filter p >>> take 5)
Only function application xs |> drop 3 |> filter p |> take 5
Re:A difference between Haskell and Common Lisp
by catnaroek on Monday December 21, 2015 @10:15AM
(#10771420)
I never understood the appeal of the pipe operator. It's a kludge to work around the need to eta-expand chained function compositions, which in turn is a kludge to work around the value restriction, which in turn is a kludge to prevent the combination of polymorphism and storage effects from breaking type soundness. Haskell doesn't need any of this.
Re:A difference between Haskell and Common Lisp
by takle on Monday December 21, 2015 @10:49AM
(#10771601)
I agree with you. I'm going to write a post about function application and composition (right-to-left / left-to-right) so other communities can stop discussing non-essential matters.
I do like the fact that the `pipe operator` is often mentioned along the bash '|' which is used in a pointfree style.
Well it might make sense sometimes, so its good to know one's options :)
p x y z = f (g x y) z
p = ((.) f) . g
Re:A difference between Haskell and Common Lisp
by catnaroek on Monday December 21, 2015 @10:53AM
(#10771623)
Of course, something is very wrong if you ever use a section of the function composition operator. Use point-free within reason... :-p
Re:A difference between Haskell and Common Lisp
by klibertp on Monday December 21, 2015 @04:14PM
(#10773558)
Or go completely, absolutely nuts with point-free and use J (http://www.jsoftware.com/).
Re:A difference between Haskell and Common Lisp
by fnordsensei on Monday December 21, 2015 @09:41AM
(#10771227)
Is
take 5 . filter p . drop 3
An anonymous function call in Haskell? I don't know the language (although it's on my to-learn sequence).
Re:A difference between Haskell and Common Lisp
by marcosdumay on Monday December 21, 2015 @11:56AM
(#10771996)
Yes. It's three anonymous ("take 5", "filter p" and "drop 3") functions composed by the "." operator, creating another anonymous function.
One of the types, for example:
take :: Int -> [a] -> [a]
What means a function that takes an Int argument and returns another function, that takes a list and returns a list of the same type.
Re:A difference between Haskell and Common Lisp
by mietek on Monday December 21, 2015 @10:33AM
(#10771505)
Yes, written in pointless style. You could make it less pointless by replacing the (.)s with a point.
\xs -> take 5 (filter p (drop 3 xs))
https://wiki.haskell.org/Pointfree
Re:A difference between Haskell and Common Lisp
by catnaroek on Monday December 21, 2015 @09:42AM
(#10771241)
It's an anonymous function, which it not being called.
[deleted]
Re:A difference between Haskell and Common Lisp
by catnaroek on Monday December 21, 2015 @11:10AM
(#10771705)
You probably meant to reply to mietek.
Re:A difference between Haskell and Common Lisp
by pja on Monday December 21, 2015 @12:04PM
(#10772046)
ghci will (usually) tell you:
phil@arod:~$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :t take 5 . filter (\ _ -> True) . drop 3
take 5 . filter (\ _ -> True) . drop 3 :: [a] -> [a]
So it’s a function from List of a to List of a
Re:A difference between Haskell and Common Lisp
by ogroide on Monday December 21, 2015 @10:12AM
(#10771394)
Is not the same, in lisp :count 5 means that you remove at most 5 elements, so that the result can be a list of 100 elements, while take 5 will always produce a sequence with at most 5 elements.
(remove-if-not #'evenp (loop for i below 10 collect i) :count 3 :start 0) result is (0 2 4 6 7 8 9), there are three elements deleted.
Re:A difference between Haskell and Common Lisp
by fnordsensei on Monday December 21, 2015 @10:43AM
(#10771569)
Well, that is different, but I suppose the Haskell example suffers from the same difference then.
Re:A difference between Haskell and Common Lisp
by agumonkey on Monday December 21, 2015 @09:48AM
(#10771268)
Funny how when I think about Lisp I think about that kind of code, while other people see elisp imperative, autolisp and common-lisp full-featured system.
Re:A difference between Haskell and Common Lisp
by icholy on Monday December 21, 2015 @09:31AM
(#10771174)
Unlike CL/EL, Clojure is lazy by default. So it's closer to Haskell in that regard.
Re:A difference between Haskell and Common Lisp
by catnaroek on Monday December 21, 2015 @09:31AM
(#10771179)
Clojure isn't lazy by default. It is a strict language with lazy streams in the standard library.
Rather than
It seems to me like most Clojure users would do something like which is much closer to