On Sun, May 2, 2010 at 4:10 PM, Don Stewart wrote:

I don't believe anyone has written a "Programming Haskell in the Large" book (or any other similar functional language??), but there is lots of experience in this community working on big, long lived code bases.

Some key points: [...]    * picking a good data type (like a zipper) will make hundreds of          unit tests meaningless -- improving productivity.

Don, What sort of tests were you thinking of that a zipper would render pointless? Could you elaborate? Thanks, Brad

On Sun, 02/May/2010 at 13:10 -0700, Don Stewart wrote:

* Avoid partial functions

Why? Edgar

On 3 May 2010 11:18, Edgar Z. Alvarenga wrote:

On Sun, 02/May/2010 at 13:10 -0700, Don Stewart wrote:

...

    * Avoid partial functions

Why?

What does "head []" do again? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

I'm a little confused about this too. I've seen many functions defined like: f x = (\s -> ...) which is a partial function because it returns a function and is the same as: f x s = ... Off the top of my head the State monad makes extensive use if this style. Is this bad? - deech On 5/2/10, Bradford Larsen wrote:

On Sun, May 2, 2010 at 9:18 PM, Edgar Z. Alvarenga wrote:

...

On Sun, 02/May/2010 at 13:10 -0700, Don Stewart wrote:

...

    * Avoid partial functions

Why?

Edgar

Ever place you use a partial function, you need to verify that its usage is in fact safe. Otherwise, you risk pattern match failures, undefined, nontermination, and other types of nasties.

If you can structure your code so none of your functions are partial, verification that their usage is safe is a whole lot easier. :-)

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

Cool. That makes way more sense. I thought that ghc -Wall picked these up. So at least this problem would go away if warnings were turned on (and heeded) by default. Besides that from my own experience I'd strongly encourage people to use HLint [1] . -deech [1 ] http://hackage.haskell.org/package/hlint On 5/3/10, Ivan Miljenovic wrote:

On 3 May 2010 14:17, aditya siram wrote:

...

I'm a little confused about this too. I've seen many functions defined like: f x = (\s -> ...) which is a partial function because it returns a function and is the same as: f x s = ...

No, that's a partially applied function.

A partial function is one such as:

secondElement (_:x:_) = x

Note that it is only defined for lists with at least two elements, for any other list (i.e. singleton or empty) it will throw an error; -fwarn-incomplete-patterns (which is included in -Wall) tells you about these.

You can also argue that functions such as head are partial, as they explicitly throw an error if the input data isn't correct.

Partial functions are bad because if you accidentally use one the wrong way, your entire program crashes in a flaming wreck. It's much better to do something like this:

safeSecondElement (_:x:_) = Just x safeSecondElement _ = Nothing

This will work with all possible input types.

For more information, see http://en.wikipedia.org/wiki/Partial_function (from the mathematical perspective).

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Sun, May 2, 2010 at 9:24 PM, Ivan Miljenovic wrote:

On 3 May 2010 14:17, aditya siram wrote:

...

I'm a little confused about this too. I've seen many functions defined like: f x = (\s -> ...) which is a partial function because it returns a function and is the same as: f x s = ...

No, that's a partially applied function.

A partial function is one such as:

secondElement (_:x:_) = x

Note that it is only defined for lists with at least two elements, for any other list (i.e. singleton or empty) it will throw an error; -fwarn-incomplete-patterns (which is included in -Wall) tells you about these.

You can also argue that functions such as head are partial, as they explicitly throw an error if the input data isn't correct.

Partial functions are bad because if you accidentally use one the wrong way, your entire program crashes in a flaming wreck.  It's much better to do something like this:

safeSecondElement (_:x:_) = Just x safeSecondElement _         = Nothing

This will work with all possible input types.

For more information, see http://en.wikipedia.org/wiki/Partial_function (from the mathematical perspective).

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Of course, there are situations where it is really awkward to not use partial functions, basically because you *know* that an invariant is satisfied and there is no sane course of action if it isn't. To take a contrived example: f ys = let xs = (1:ys) in last xs uses the partial function "last". Rewriting it in the "non-partial style" gives f ys = case (1:ys) of [] -> Nothing xs -> Just (last xs) but what possible meaning could a caller of the function ascribe to a "Nothing" result? It just means that there is a bug in f, which is what an error would tell you anyway. Of course, this particular function could easily be rewritten in such a way to be total, but I believe there are more complex examples where it is awkward/impossible to do so. Alex

On May 3, 2010, at 6:35 AM, Alexander Dunlap wrote:

Of course, there are situations where it is really awkward to not use partial functions, basically because you *know* that an invariant is satisfied

That falls under Don's: "Use types to encode the design into a machine checkable form" Or as Yaron Minsky put it: "Make illegal states unrepresentable" When you do this, your functions don't need to be partial, if you know that it doesn't matter. Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

On Sun, 2010-05-02 at 21:35 -0700, Alexander Dunlap wrote:

f ys = let xs = (1:ys) in last xs

uses the partial function "last". Rewriting it in the "non-partial style" gives

f ys = case (1:ys) of [] -> Nothing xs -> Just (last xs)

I guess it is more like f :: Num a => [a] -> a f = fromMaybe 1 . safeLast Regards

There are many ways to handle errors in Haskell. The Maybe method is the simplest but it also comes with a little overhead, since you always have to unpack the Maybe a value return, and finally I often end up by doing something like : maybe (error "Unexpected Nothing") id someSafeFunction when you absolutely do not expect your code to return a Nothing here. There's also the possibility to handle errors through a monad (e.g. using Maybe as a monad), but all your functions must be designed as such. I don't how the Error monad could be used there, I've never studied it... I think using explicit exceptions is better in that case : secondElement (_:x:_) = x secondElement _ = error "secondElement: length < 2" The major problem with exceptions is that Haskell has -- afaik -- no notion of traceback (to know exactly where the exception was raised). For instance, here, if secondElement is called more than once in your code, if you get the exception, you won't be immediately able to tell which part of the code raised it. 2010/5/3 Rafael Cunha de Almeida

...

On 3 May 2010 14:17, aditya siram wrote:

...

I'm a little confused about this too. I've seen many functions defined

Ivan Miljenovic disse: like:

...

...

f x = (\s -> ...) which is a partial function because it returns a function and is the same as: f x s = ...

No, that's a partially applied function.

A partial function is one such as:

secondElement (_:x:_) = x

Note that it is only defined for lists with at least two elements, for any other list (i.e. singleton or empty) it will throw an error; -fwarn-incomplete-patterns (which is included in -Wall) tells you about these.

You can also argue that functions such as head are partial, as they explicitly throw an error if the input data isn't correct.

Partial functions are bad because if you accidentally use one the wrong way, your entire program crashes in a flaming wreck. It's much better to do something like this:

safeSecondElement (_:x:_) = Just x safeSecondElement _ = Nothing

This will work with all possible input types.

I don't think that safeSecondElement is worse than secondElement. I think it's better for the program to crash right away when you try to do something that doesn't make sense.

Getting the secondElement of a list with one or less elements doesn't make sense, so you are definetely doing something wrong if you expected the list to have two elements, but it doesn't. It's best that the program crashes there, than propagate the error and crash somewhere else or, worse, not crash at all and give a wrong answer. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

G'day all. Quoting aditya siram :

I'm a little confused about this too. I've seen many functions defined like: f x = (\s -> ...) which is a partial function because it returns a function and is the same as: f x s = ...

Off the top of my head the State monad makes extensive use if this style. Is this bad?

It's not inherently bad style. In the State/Reader monads, the passed-in parameter is part of the type: type State s a = s -> (s,a) f :: Foo -> State s a Since f has only one argument according to its type signature, it makes sense to give it only argument in its rules as well: f x = \s -> ... This re-enforces the fact that s is an implementation detail of State. It is an error in Haskell to have multiple rules for a function with different arities. So this, for example, is illegal: f True = length f False [] = 3 f False (_:_) = 2 If there were a good reason for writing the first rule in a point-free manner, it would be perfectly reasonable to rewrite this using an explicit lambda. There are also performance issues which may be relevant. GHC doesn't break up lambdas to do let-floating, so if that's what you want, you may need to express it manually: data TreeSet a = Null | Singleton a | Doubleton a a | Branch a TreeSet TreeSet elem :: (Ord a) => TreeSet a -> a -> Bool elem Null = \p -> False elem (Singleton p1) = \p -> p == p1 elem (Doubleton p1 p2) = \p -> p == p1 || p == p2 elem (Branch p' l r) = let elem_l = elem l elem_r = elem r in \p -> if p < p' then elem_l p else elem_r p Like all situations where you've got more than one way to express something, which one you pick depends on what you're trying to say. Cheers, Andrew Bromage