4 ms·
> The given Haskell example doesn't support their claim that >> This is shorter than the equivalent in an applicative language, because we have to name the inp
by yakubin 4y ago
> The given Haskell example doesn't support their claim that
>> This is shorter than the equivalent in an applicative language, because we have to name the input argument, that is only used once.*
Are you saying that in your eyes the Common Lisp and Haskell snippets are equally terse? To me the Haskell snippet looks a lot shorter and easier to read. Counting tokens also supports that judgement.
- dreamcompiler 4y agoThe Common Lisp example is a tiny bit disingenuous. Common Lisp programmers rarely write (function evenp) but instead write the shorthand version #'evenp
- Jtsummers 4y agoAlso, Common Lisp has a complement function which produces a new Boolean function with the negation of the result: (complement #'evenp) vs the example: (lambda (n) (not (evenp n))) Not much shorter by character count, but it is shorter by token count. http://clhs.lisp.se/Body/f_comple.htm http://clhs.lisp.se/Body/f_comple.htm
- simiones 4y agoThe article seemed to be claiming that the Factor example was shorter than both the CL and Haskell ones. While the CL one is clearly the longest, the Haskell example seems at least as terse as the Factor example (`( 4 > )` in Haskell, vs `[ 4 > ]` in Factor - not sure if the parens in Haskell and the square brackets in Factor have the same amount of semantic weight though).
- marcosdumay 4y agoPersonally, I attribute more "semantic weight" to the brackets in Factor. They have a much heavier definition of creating a lambda than Haskell's parenthesis, that only group operations. (But I'm not sure if I prefer terseness to that level. Explicitness has value too.)
- yakubin 4y agoOh, got it. I got confused, because the Haskell snippet is written in a point-free, not applicative style.