notes-computer-programming-programmingLanguageDesign-prosAndCons-jasperErrorNotes1

"Error messages from Complex types

In Yesod we have some complex types in a few key places. And we are fine with having complex types internally. However, exposing them in an interface is a very delicate matter- users have to be able to understand error messages. Yesod has abandoned certain uses of polymorphism due to this issue. And we would still like to make error messages better.

Reading error messages is an interface through which programmers learn Haskell. Is there a way to make error messages better? The most interesting approach I can think of is to somehow let the library writer specify certain error messages. "


ArgumentCheckingException?:

--

http://docs.python.org/2/library/exceptions.html

--

interesting Scala idiom:

scala Options (like Haskell maybes) are implicitly coerced to sequences with zero elements (for None) or sequences with one element (for Some), allowing you to use flatMap (which is like concat(map())), to take a sequence, map over it producing a sequence of Options, and return only a sequence of the valid elements, e.g.

scala> val l = List(1,2,3,4,5) scala> def f(x: Int) = if (v > 2) Some(v) else None

scala> l.map(x => f(x)) res66: List[Option[Int]] = List(None, None, Some(3), Some(4), Some(5))

scala> l.flatMap(x => f(x)) res67: List[Int] = List(3, 4, 5)

-- http://www.brunton-spall.co.uk/post/2011/12/02/map-map-and-flatmap-in-scala/

--

http://250bpm.com/blog:4

 Why should I have written ZeroMQ in C, not C++ (part I)

--