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
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...
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.h... -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr
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.
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
On 2008 Sep 14, at 10:01, Stephan Friedrichs wrote:
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 ;)
MonadZero is what "fail" replaced in Haskell98. Many people consider this a serious mistake. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Hi,
On Sun, Sep 14, 2008 at 7:01 AM, Stephan Friedrichs
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
On Sat, Sep 13, 2008 at 11:19 AM, Stephan Friedrichs
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
participants (5)
-
Brandon S. Allbery KF8NH -
Iavor Diatchki -
Johannes Waldmann -
Ryan Ingram -
Stephan Friedrichs