On Wed, 9 Feb 2005, Henning Thielemann wrote:

On Wed, 9 Feb 2005, Bayley, Alistair wrote:

...

Were you thinking of something like "[n] Things a Java Programmer Should Know About Ruby" ? http://jimweirich.tadalist.com/lists/public/14055

Perhaps you'd like to start a page on the wiki. A link from here, maybe? http://haskell.org/hawiki/FrequentlyAskedQuestions

Is there also a Wiki page about things you should avoid?

Since I couldn't find one, I started one on my own: http://www.haskell.org/hawiki/ThingsToAvoid I consider 'length', guards and proper recursion anchors.

...

Is there also a Wiki page about things you should avoid?

Since I couldn't find one, I started one on my own:

http://www.haskell.org/hawiki/ThingsToAvoid

I consider 'length', guards and proper recursion anchors.

foo (n+1) = ... n ... n ... n ... is much clearer than foo n = let n' = n + 1 in n' `seq` ... n' ... n' ... n' ... On the wiki, you claim data Natural = Zero | Successor Natural They are implemented using binary numbers and it is not even tried to simulate the behaviour of Natural (e.g. laziness). Thus I wouldn't state, that 3 > matches the pattern 2+1. If however, you had defined data Nat = Zero | Succ !Nat,

[Moving the discussion from the wiki to the mailing list until we've reached some kind of consensus] ad n+k-patterns This old discussion seems kind of relevant. http://www.dcs.gla.ac.uk/mail-www/haskell/msg01131.html In my opinion, there's no reason to avoid (n+1)-patterns. Recursion is the natural definition of many functions on the natural numbers, just like on lists, trees or any other ADT. There just happens to be a more efficient representation of naturals than as Peano numbers. There are indeed circumstances where pattern matching would still be possible, but Nat would behave exactly as the (n+1) - pattern. ad guards I agree that guards are not always the right way to do it (as in the example you mentioned on the wiki which was bad Haskell code anyway). However, they have valid uses that can't be easily/naturally expressed without them. A typical example might be

foo (App e1 e2) | e1 `myGuard` e2 = App (foo e1) (foo e2) foo (Lambda v e) = Lambda v (foo e) foo (App e1 e2) = App (bar e1) (bar e2) ...

So instead of saying "guards are bad", i think there should rather be an explanation when guards are appropriate. Altogether, the spirit of the page seems to be "use as little syntactic sugar as possible" which maybe appropriate if it is aimed at newbies, who often overuse syntactic sugar (do-notation). However, I like most of the syntactic sugar provided by Haskell/Ghc, and it is one reason why Haskell is such nice language, so I don't think we should advocate unsugaring all our programs. Thomas

On Thu, 10 Feb 2005 12:50:16 +0100 (MET), Henning Thielemann wrote:

On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:

...

Altogether, the spirit of the page seems to be "use as little syntactic sugar as possible" which maybe appropriate if it is aimed at newbies, who often overuse syntactic sugar (do-notation).

This overuse is what I observed and what I like to reduce. There are many people advocating Haskell just because of the sugar, which let interested people fail to see what's essential for Haskell. When someone says to me that there is a new language which I should know of because it supports definition of infix operators and list comprehension, I shake my head and wonder why he don't simply stick to Perl, Python, C++ or whatever.

I don't believe that Haskell advocacy usually happens on such a superficial level, in fact most users of curly-braced languages hate Haskell's syntax, so that won't be an argument for Haskell anyway. Looking at it closer, syntax often makes a huge difference. Haskell is an many ways similar to mathematical notation, which allows to express complicated concepts in a concise way and happens to use a lot of syntactic sugar. There should be no doubt about that 1 + 2 + 3 is easier for humans to parse than (+ (+ 1 2)). This becomes especially important when you are embedding a domain specific language into Haskell. Allowing combinators to be used infix make code more readable, better understandable, reduces parenthesis, and sometimes resolves the question in which order the arguments of the functions appear. It's not strictly necessary, but is a big advantage over postfix-languages.

What I forgot: Each new syntactic sugar is something more, a reader must know, a compiler and debugger developer must implement and test, a source code formatter, highlighter, documentation extractor or code transformer must respect. We should try harder to reduce these extensions rather than inventing new ones. Leave the award for the most complicated syntax for C++! :-] Ideally, new syntactic sugar is self-explanatory, and this is the case for most of Haskell's sugar (maybe in contrast to C++). The fact that some tools get a little more complicated doesn't bother me much if it helps me write my program in a more concise way.

That's why I want to stress that the syntactic sugar is much less important or even necessary than generally believed. I hope that the examples clarify that. Yeah, as long as it is explained and clearly marked as an opinion (as it is now), that's ok. One reason that I got so excited about that is because I don't like the current situation with (n+k)-patterns: Everybody says they're evil, but hardly anybody can explain why he thinks so.

Thomas

Hi, On Thu, 10 Feb 2005 16:18:19 -0800, Iavor Diatchki wrote:

...

because I don't like the current situation with (n+k)-patterns: Everybody says they're evil, but hardly anybody can explain why he thinks so.

I think 'evil' may be a little too strong. I think the usual argument against 'n+k' patterns is that: i) they are a very special case, and may be confusing as they make it look as if '+' was a constructor, which it is not agreed

ii) they lead to some weird syntactic complications, e.g. x + 3 = 5 defines a function called '+', while (x + 3) = 5 defines a variable 'x' to be equal to 2. and there is other weirdness like: x + 2 : xs = ... does this define '+' or ('x' and 'xs')? i think it is '+'. IMO, that's not a big problem, because if ambigouties arise, only one of the possible meanings will compile (e.g. if you use + somewhere else in the module, ghc will complain about an ambigous occurrence of `+'). All (rather strange) other cases are caught by ghc -Wall.

I found another disadvantage: iii) As a side effects of how n+k patterns work, each instance of the Num class must also be an instance of Eq, which of course doesn't make sense for all numeric types.

anyways when used as intended 'n+k' are cute. it is not clear if the complications in the language specification and implementaions are worth the trouble though. It's true that their functionality can be easily expressed without them.

I like to see them (well, n+1 patterns) as a special case of views because they allow numbers to be matched against something that is not a constructor and involve a computation on pattern matching. An unambigous replacement using views could look somewhat like

foo Zero = 1 foo (Succ n) = 2 * foo n

Thomas

Iavor Diatchki writes in response to Thomas Jäger

Literal patterns need equality: f 2 = e is like: f x | x == 2 = e

These do not force the 'Num' class to be a superclass of 'Ord' or 'Eq'. If 'Num' was not a superclass of 'Eq', whenver you used a literal pattern there would be an extra constraint that there should be equality on the corresponding type.

You mean of course that Eq is a superclass of Num, not the reverse. Anyway, I always hated this, especially working with functional objects for which I had some arithmetic defined... Jerzy Karczmarczuk

On Feb 10, 2005, at 6:50 AM, Henning Thielemann wrote:

On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:

...

Altogether, the spirit of the page seems to be "use as little syntactic sugar as possible" which maybe appropriate if it is aimed at newbies, who often overuse syntactic sugar (do-notation).

This overuse is what I observed and what I like to reduce. There are many people advocating Haskell just because of the sugar, which let interested people fail to see what's essential for Haskell. When someone says to me that there is a new language which I should know of because it supports definition of infix operators and list comprehension, I shake my head and wonder why he don't simply stick to Perl, Python, C++ or whatever.

If you're trying to avoid obscurity, why advocate point-free style? I ask this question to be deliberately provocative; I'm not trying to single you out in particular. So, to everybody: What's so great about point-free style? Is it really clear or obvious what

map . (+)

means? Contrast this with

\n -> map (+n)

or

\n xs -> map (+n) xs

I submit that, while it is possible to develop a reading knowledge of point-free style, non-trivial use of point-free computations---compositions of functions with arity greater than 1, as above, compositions of sections of composition or application, arrow notation without the sugar, and so forth---will always be more difficult to read and understand than the direct version. I submit that this is true even if one is familiar with point-free programming and skilled in its use. Even something as simple as eta-reduction (as in the second and third functions above) can seriously obscure the meaning of program code by concealing the natural arity of a function. -Jan-Willem Maessen

Am Donnerstag, 10. Februar 2005 16:53 schrieb Peter Simons:

Jan-Willem Maessen writes:

...

Is it really clear or obvious what

map . (+)

means?

Yes, it is perfectly obvious once you write it like this:

incrEach :: Integer -> [Integer] -> [Integer] incrEach = map . (+)

Yes, but without the type signature it isn't really (to a beginner, at least).

Now compare that to the following function, which does the some thing but without point-free notation:

incrEach' :: Integer -> [Integer] -> [Integer] incrEach' i is = is >>= \i' -> return (i'+i)

Ugh, but I think the natural way to write it looks more like incrAll :: Integer -> [Integer] -> [Integer] incrAll n ks = map (+n) ks which is no less readable than map . (+).

Which one is harder to read? ;-)

Peter

Daniel

Am Donnerstag, 10. Februar 2005 20:50 schrieben Sie:

...

...

incrEach' i is = is >>= \i' -> return (i'+i)

Ugh, but I think the natural way to write it looks more like

incrAll :: Integer -> [Integer] -> [Integer] incrAll n ks = map (+n) ks

which is no less readable than map . (+).

I tend to like point-freeing only the last argument, which gives something

like:

...

incrAll n = map (+n)

which I think (personally) is the most readable.

I think so, too. And in general, I think that sometimes points-free is more readable than pointed, sometimes it's the other way round and sometimes a mixed form is best to read. So I choose not to consistently write points-free nor pointed (sorry, Matthew) but what I judge to be most readable.

-- Hal Daume III | hdaume@isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

Daniel

I have to agree (although I suspect few others will :)) matt On 11/02/2005, at 1:23 AM, Jan-Willem Maessen wrote:

On Feb 10, 2005, at 6:50 AM, Henning Thielemann wrote:

...

On Thu, 10 Feb 2005, [ISO-8859-1] Thomas Jäger wrote:

...

Altogether, the spirit of the page seems to be "use as little syntactic sugar as possible" which maybe appropriate if it is aimed at newbies, who often overuse syntactic sugar (do-notation).

This overuse is what I observed and what I like to reduce. There are many people advocating Haskell just because of the sugar, which let interested people fail to see what's essential for Haskell. When someone says to me that there is a new language which I should know of because it supports definition of infix operators and list comprehension, I shake my head and wonder why he don't simply stick to Perl, Python, C++ or whatever.

If you're trying to avoid obscurity, why advocate point-free style?

I ask this question to be deliberately provocative; I'm not trying to single you out in particular. So, to everybody: What's so great about point-free style?

Is it really clear or obvious what

...

map . (+)

means? Contrast this with

...

\n -> map (+n)

or

...

\n xs -> map (+n) xs

I submit that, while it is possible to develop a reading knowledge of point-free style, non-trivial use of point-free computations---compositions of functions with arity greater than 1, as above, compositions of sections of composition or application, arrow notation without the sugar, and so forth---will always be more difficult to read and understand than the direct version. I submit that this is true even if one is familiar with point-free programming and skilled in its use. Even something as simple as eta-reduction (as in the second and third functions above) can seriously obscure the meaning of program code by concealing the natural arity of a function.

-Jan-Willem Maessen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hmm, Hugs gives me this: (.) . (.) . (.) :: (a -> b) -> (c -> d -> e -> a) -> c -> d -> e -> b which I think is correct, if still not transparent in its meaning. (ghci gives me a slightly re-named and explicitly quantified variation). Basically, the idea is that this sort of expression, with n occurrences of *parenthesized* dots (and n-1 unparenthesized ones interspersed) is the "compose a 1-argument function with an n-argument function" variant of the composition operator (in the "obvious" way). For small n, this allows one to get around the limitations of (.) for some points-free applications: for large n, it probably isn't worth it. (Appropriate definitions of "small" and "large" tend to vary :) ). -- Fritz Example nicked from the file I attached to the last message: (.<) = (.) . (.) stutter = concat .< replicate Here the use of the "<" symbol is onomatopoeic (or the graphical homologue of that): the two "arms" of the symbol, branching out to the right, suggest that this variant of the composition operator, (.<), takes a 2-argument function on the right. On Feb 11, 2005, at 12:00 AM, Ketil Malde wrote:

... Type signatures help, of course. E.g. with the previously mentioned and rather cryptic function

(.) . (.) .(.)

I entered it into GHCi, and got

:: forall a a b c a. (b -> c) -> (a -> a -> a -> b) -> a -> a -> a -> c

and it suddenly is much clearer what it does.

-kzm -- If I haven't seen further, it is by standing in the footprints of giants

[I drafted this response some time ago, but didn't send it, so apologies if I am re-covering old ground...] At 09:23 10/02/05 -0500, Jan-Willem Maessen wrote:

If you're trying to avoid obscurity, why advocate point-free style?

Some time ago, I asked an experienced Haskell programmer about the extent to which they used point-free style in day-to-day programming, and the response I got was to the effect that they use point-full style a fair amount. The ...er... point, I think, is that it is easier to reason equationally with point-free programs, even if the intended computation is often easier for mere mortals to see when named values are used. So point-free style helps when trying to apply program transformation techniques, and translation to make greater use of point-free idioms may be a useful precursor to transforming a program. Something I have noticed is that, as one gets more used to using higher order functions, it is often more elegant to express a computation by composition of functions, but in so doing one has to discard preconceived notions of what makes an efficient program. I think it comes down to this: learn to be comfortable with both styles, and be prepared to use the one that best expressed the intended solution (and is easiest to understand) in any given context. #g -- At 09:23 10/02/05 -0500, Jan-Willem Maessen wrote:

If you're trying to avoid obscurity, why advocate point-free style? I ask this question to be deliberately provocative; I'm not trying to single you out in particular. So, to everybody: What's so great about point-free style?

Is it really clear or obvious what

...

map . (+)

means? Contrast this with

...

\n -> map (+n)

or

...

\n xs -> map (+n) xs

I submit that, while it is possible to develop a reading knowledge of point-free style, non-trivial use of point-free computations---compositions of functions with arity greater than 1, as above, compositions of sections of composition or application, arrow notation without the sugar, and so forth---will always be more difficult to read and understand than the direct version. I submit that this is true even if one is familiar with point-free programming and skilled in its use. Even something as simple as eta-reduction (as in the second and third functions above) can seriously obscure the meaning of program code by concealing the natural arity of a function.

-Jan-Willem Maessen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

On Wed, Feb 09, 2005 at 02:54:12PM +0100, Henning Thielemann wrote:

On Wed, 9 Feb 2005, Henning Thielemann wrote:

...

Is there also a Wiki page about things you should avoid?

Since I couldn't find one, I started one on my own:

http://www.haskell.org/hawiki/ThingsToAvoid

I consider 'length', guards and proper recursion anchors.

Oops, I just forgot a comment to my latest update: I added an example to illustrate the fromInteger-in-a-pattern case. -- Nobody can be exactly like me. Even I have trouble doing it.

On Fri, 11 Feb 2005, Remi Turk wrote:

1) It's talking about the compiler having difficulty with some warnings when using guards.

http://www.haskell.org//pipermail/haskell-cafe/2005-January/008290.html

f x | odd x = ... | even x = ...

GHC does complain. I would also call it Bad Code, but if it's what you mean, _this_ example should be in the wiki.

Yes, your example is better.

2) foo xs | length xs == 1 = bar (head xs) As already said in "Don't ask for the length of a list, if you don't need it", this usage of length is bad in itself, and doesn't really help the argument against patterns IMO.

I have seen it similarly in the example I give below at that page. So I found it worth noting that some guards can nicely be replaced by simple patterns. More examples are welcome. May be we should replace it by foo xs | not (null xs) = bar (head xs) vs. foo (x:_) = bar x This example might be useful, too: foo x | x == 0 = blub x /= 0 = bla vs. foo 0 = blub foo _ = bla

3) the pattern guards extension. I have two objections against this one. First, I don't think it's a good idea to talk about a non-standard extension like pattern guards in a wiki about newbie-problems.

It was given to me as a good example why Guards are invaluable: http://www.haskell.org//pipermail/haskell-cafe/2005-January/008320.html

P.P.S. Does a piece about "Avoid explicit lambda's" stand any chance of not being removed? (Basically about "\x y -> x + y" vs "(+)", and "when it gets more complicated it probably deserves a name.")

Nice!