Re: [Haskell-cafe] Views
I think the crux of the matter was that a monad is too general. Either there is a result or there is not. That's precisely the intended use of a Maybe. Indeed Monad m = is dangerous here because not every Monad has a reasonable definition of fail. But that seems to be a problem in the (current) definition of Monad, and its solution was MonadZero, no? J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Views
Johannes Waldmann wrote:
a) ... to use Maybe
b) ... to provide my own Data.Heap.View type
leave the choice up to the programmer,
and provide a generic interface,
accepting any MonadZero (*) instance.
cf. Data.Set.maxView
AFAIK there has been a vivid discussion about that. I think the crux of
the matter was that a monad is too general. Either there is a result or
there is not. That's precisely the intended use of a Maybe.
Besides, I just learned that Data.Map.{lookup,minView,maxView} and the
like have been modified to return a Maybe in the current GHC head
branch, see [1]. This suggests using Maybe in my case as well.
[...]
[1]
http://www.haskell.org/ghc/dist/current/docs/libraries/containers/Data-Map.html
--
Früher hieß es ja: Ich denke, also bin ich.
Heute weiß man: Es geht auch so.
- Dieter Nuhr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Views
Johannes Waldmann wrote: I think the crux of the matter was that a monad is too general. Either there is a result or there is not. That's precisely the intended use of a Maybe. Indeed Monad m = is dangerous here because not every Monad has a reasonable definition of fail. But that seems to be a problem in the (current) definition of Monad, and its solution was MonadZero, no? I agree that the MonadZero class with a useful 'zero' :: m a would be the right abstraction for views. But MonadZero is not part of base, mtl or any other common package, or am I missing something? Changing this is beyond a simple heap package ;) -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Views
Hi, On Sun, Sep 14, 2008 at 7:01 AM, Stephan Friedrichs [EMAIL PROTECTED] wrote: I agree that the MonadZero class with a useful 'zero' :: m a would be the right abstraction for views. But MonadZero is not part of base, mtl or any other common package, or am I missing something? Changing this is beyond a simple heap package ;) The class ExceptionM from monadLib captures this functionality. However, for this simple case 'Maybe' seems quite enough because it is what you need most of the time. Furthermore, it does not loose any generality because you can use a function of type :: MonadZero m = Maybe a - m a, to convert to other monads, if it is necessary. -Iavor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Views
Hello! List-like data structures should IMHO provide safe versions of 'head' and 'tail' (with safe I mean 'not partial', i. e. functions that don't provoke an 'error' when called with an empty collection). As far as I know, this is usually called 'view' and and has a type signature like view :: SomeDataStructure a - View a with data View = Empty | Cons a (SomeDataStructure a) A good example for this is Data.Sequence. My question is: Why is this not expressed in terms of Maybe? view :: SomeDataStructure a - Maybe (a, SomeDataStructure a) This would be easier to use, as there's no need for a new View type and because Maybe already provides instance declarations for a lot of useful classes (Functor, Monad, etc.) and handy helper functions (e. g. 'maybe'). Then you could, for instance, say: head xs = maybe undefined fst (view xs) tail xs = maybe undefined snd (view xs) You can of course argue that you want viewl and viewr to have different types in the case of Data.Sequence, but this is not the case for other, rather one-ended, data types, is it? Long story short, my problem is the following: I want to provide a 'view' function for Data.Heap in my heap [1] package and I don't know whether... a) ... to use Maybe b) ... to provide my own Data.Heap.View type c) ... a Data.View package with a View type should be included in the containers- or even base-package. This would prevent lots of small projects from creating totally equivalent View types. Maybe there even exists a Data.View package that I didn't find? Regards, Stephan [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.3.1 -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Views
a) ... to use Maybe b) ... to provide my own Data.Heap.View type leave the choice up to the programmer, and provide a generic interface, accepting any MonadZero (*) instance. cf. Data.Set.maxView http://www.haskell.org/hoogle/?hoogle=maxView (*) ah - I forgot, MonadZero didn't quite make it, instead we have fail in Monad, and mzero in MonadPlus. Sure there must have been a reason for this... signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Views
On Sat, Sep 13, 2008 at 11:19 AM, Stephan Friedrichs [EMAIL PROTECTED] wrote: data View = Empty | Cons a (SomeDataStructure a) A good example for this is Data.Sequence. My question is: Why is this not expressed in terms of Maybe? view :: SomeDataStructure a - Maybe (a, SomeDataStructure a) I think the usual reason this is done is because it is clearer to read. Since Maybe is so generally useful, when you read code that uses it, you have to figure out what use it is being put towards. What does Nothing mean? What does Just (a,b) mean? are the kinds of questions that go through your head, and they distract you from the problem at hand. On the other hand, reading code that uses the View type, it is immediately clear what Empty and Cons mean. But you're right, Maybe has a lot of useful helper functions and instances. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
