[Haskell-cafe] [Maybe Int] sans Nothings

[Alexander Solla]

>
>
> > Personally, I find non-functional values without Eq instances to be
> > degenerate.  So I really do not mind superfluous Eq constraints.  I
> > would not hesitate to use filter ((/=) Nothing) in a function whose type
> > has no free type variables.  It's just a bit of plumbing inside of a
> > more complex function.
>
> Sometimes it seems to be better to not allow Eq on Float and Double.
> Since most algebraic laws do not hold for those types, it is more often
> an error than an intention to compare two Float values. And how to
> compare (IO a) values?


Floats, Doubles, and IO are all "degenerate" types, for the reasons you
outline.  (Admittedly, Float and Double have Eq instances, but invalid Eq
semantics)  Notice how their value semantics each depend on the machine your
runtime runs on, as opposed to merely the runtime.  Bottom is another one of
these degenerate types, since comparisons on arbitrary values are
undecidable.

Also, by thinking about function types, you often
> get interesting use cases. Thus I would not assume too quickly that a
> type will always be instantiated by types other than a function type.
> Thus I would stick to (filter isJust) and use this consistently for
> monomorphic and polymorphic types.
>

I am not suggesting (filter ((/=) Nothing)) /over/ (filter isJust).
 Obviously, once one is aware of a  better tool, one should use it.  But I
am suggesting that for simple cases which are unlikely to change in any
substantive way, we should probably just use the tools we already know of,
as opposed to searching for the "right" one.  Both might involve costs.
 There is a cost involved in going to Google, thinking up a search term,
finding that Data.Maybe has relevant functions, picking the right one.  It
takes less time to write "filter ..." than to type "haskell removing nothing
from list", for example.  When dealing with known unknowns, there is a
balance to be made, and it is not easy.

Michael's choice to ask the list imposed costs.  (Not that we mind, we're
all volunteers, after all).  But it probably took 10 minutes to get the
first reply.  He could have written a bit of code that worked correctly,
given the context of his problem, in 20 seconds.  Then again, he probably
worked on a different bit of code until somebody sent a solution, so we
probably only have to account for the time spent in context switching, for
everyone involved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110524/0752f195/attachment.htm>