monads with take-out options

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

monads with take-out options

Greg Meredith
Haskellians,

Some monads come with take-out options, e.g.
  • List
  • Set
In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad.

Some monads do not come with take-out options, IO being a notorious example.

Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available.

Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out?

Best wishes,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Jason Dagit-2


2008/11/24 Greg Meredith <[hidden email]>
Haskellians,

Some monads come with take-out options, e.g.
  • List
  • Set
In the sense that if unit : A -> List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad.

Some monads do not come with take-out options, IO being a notorious example.

I think the take-out option for IO is usually called 'main'. :)

Jason

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Greg Meredith
On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote:
> Haskellians,

> Some monads come with take-out options, e.g.
>       * List
>       * Set
> In the sense that if unit : A -> List A is given by unit a = [a], then
> taking the head of a list can be used to retrieve values from inside
> the monad.

> Some monads do not come with take-out options, IO being a notorious
> example.

> Some monads, like Maybe, sit on the fence about take-out. They'll
> provide it when it's available.

It might be pointed out that List and Set are also in this region.  In
fact, Maybe is better, in this regard, since you know, if fromJust
succeeds, that it will only have once value to return.  head might find
one value to return, no values, or even multiple values.

A better example of a monad that always has a left inverse to return is
((,) w), where w is a monoid.  In this case,

    snd . return = id :: a -> a

as desired (we always have the left inverses

    join . return = id :: m a -> m a

where join a = a >>= id).

> Now, are there references for a theory of monads and take-out options?
> For example, it seems that all sensible notions of containers have
> take-out.

Sounds reasonable.  Foldable gives you something:

  foldr const undefined

will pull out the last value visited by foldr, and agrees with head at [].

> Can we make the leap and define a container as a monad with a notion
> of take-out?

If you want.  I'd rather define a container to be Traversable; it
doesn't exclude anything interesting (that I'm aware of), and is mostly
more powerful.

> Has this been done?

Are you familiar at all with Foldable
(http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t%3AFoldable) and Traversable (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html#t%3ATraversable)

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Greg Meredith
Jonathan,

Nice! Thanks. In addition to implementations, do we have more mathematical accounts? Let me expose more of my motives.
  • i am interested in a first-principles notion of data. Neither lambda nor π-calculus come with a criterion for determining which terms represent data and which programs. You can shoe-horn in such notions -- and it is clear that practical programming relies on such a separation -- but along come nice abstractions like generic programming and the boundary starts moving again. (Note, also that one of the reasons i mention π-calculus is because when you start shipping data between processes you'd like to know that this term really is data and not some nasty little program...) One step towards a first-principles characterization of data (as separate from program) is a first-principles characterization of containers.
    • Along these lines Barry Jay's pattern-matching calculus is an intriguing step towards such a characterization. This also links up with Foldable and Traversable.
    • i also looked at variants of Wischik's fusion calculus in which Abramsky's proof expressions characterize the notion of shippable data. (Part of the intuition here is that shippable data really ought to have a terminating access property for access to some interior region. The linear types for proof expressions guarantee such a property for all well-typed terms.)
  • There is a real tension between nominal strategies and structural strategies for accessing data. This is very stark when one starts adding notions of data to the  π-calculus -- which is entirely nominal in characterization. Moreover, accessing some piece of data by path is natural, obvious and programmatically extensible. Accessing something by name is fast. These two ideas come together if one's nominal technology (think Gabbay-Pitt's freshness widgetry) comes with a notion of names that have structure.*
  • Finally, i think the notion of take-out option has something to do with being able to demarcate regions. In this sense i think there is a very deep connection with  Oleg's investigations of delimited continuations and -- forgive the leap -- Linda tuple spaces.
As i've tried to indicate, in much the same way that monad is a very, very general abstraction, i believe that there are suitably general abstractions that account for a broad range of phenomena and still usefully separate a notion of data from a notion of program. The category theoretic account of monad plays a very central role in exposing the generality of the abstraction (while Haskell's presentation has played a very central role in understanding the utility of such a general abstractin). A similarly axiomatic account of the separation of program from data could have applicability and utility we haven't even dreamed of yet.

Best wishes,

--greg

* i simply cannot resist re-counting an insight that i got from Walter Fontana, Harvard Systems Biology, when we worked together. In some sense the dividing line between alchemy and chemistry is the periodic table. Before the development of the periodic table a good deal of human investigation of material properties could be seen as falling under the rubric alchemy. After it, chemistry. If you stare at the periodic table you see that the element names do not matter. They are merely convenient ways of referring to the positional information of the table. From a position in the table you can account for and predict all kind of properties of elements (notice that all the noble gases line up on the right!). Positions in the table -- kinds of element -- can be seen as 'names with structure', the structure of which determines the properties of instances of said kind. i believe that a first-principles account of the separation of program and data could have as big an impact on our understanding of the properties of computation as the development of the periodic table had on our understanding of material properties.

On Mon, Nov 24, 2008 at 2:30 PM, Jonathan Cast <[hidden email]> wrote:
On Mon, 2008-11-24 at 14:06 -0800, Greg Meredith wrote:
> Haskellians,

> Some monads come with take-out options, e.g.
>       * List
>       * Set
> In the sense that if unit : A -> List A is given by unit a = [a], then
> taking the head of a list can be used to retrieve values from inside
> the monad.

> Some monads do not come with take-out options, IO being a notorious
> example.

> Some monads, like Maybe, sit on the fence about take-out. They'll
> provide it when it's available.

It might be pointed out that List and Set are also in this region.  In
fact, Maybe is better, in this regard, since you know, if fromJust
succeeds, that it will only have once value to return.  head might find
one value to return, no values, or even multiple values.

A better example of a monad that always has a left inverse to return is
((,) w), where w is a monoid.  In this case,

   snd . return = id :: a -> a

as desired (we always have the left inverses

   join . return = id :: m a -> m a

where join a = a >>= id).

> Now, are there references for a theory of monads and take-out options?
> For example, it seems that all sensible notions of containers have
> take-out.

Sounds reasonable.  Foldable gives you something:

 foldr const undefined

will pull out the last value visited by foldr, and agrees with head at [].

> Can we make the leap and define a container as a monad with a notion
> of take-out?

If you want.  I'd rather define a container to be Traversable; it
doesn't exclude anything interesting (that I'm aware of), and is mostly
more powerful.

> Has this been done?

Are you familiar at all with Foldable
(http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t%3AFoldable) and Traversable (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html#t%3ATraversable)

jcc





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

John Meacham
In reply to this post by Greg Meredith
On Mon, Nov 24, 2008 at 02:06:33PM -0800, Greg Meredith wrote:
> Now, are there references for a theory of monads and take-out options? For
> example, it seems that all sensible notions of containers have take-out. Can
> we make the leap and define a container as a monad with a notion of
> take-out? Has this been done? Are there reasons for not doing? Can we say
> what conditions are necessary to ensure a notion of take-out?

Yes, you are describing 'co-monads'.

here is an example that a quick web search brought up, and there was a
paper on them and their properties published a while ago
http://www.eyrie.org/~zednenem/2004/hsce/Control.Comonad.html

the duals in that version are

extract - return
duplicate - join
extend  - flip (>>=) (more or less)

        John


--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Claus Reinke
In reply to this post by Greg Meredith
>   - i am interested in a first-principles notion of data. Neither lambda
>   nor π-calculus come with a criterion for determining which terms represent
>   data and which programs. You can shoe-horn in such notions -- and it is
>   clear that practical programming relies on such a separation -- but along
>   come nice abstractions like generic programming and the boundary starts
>   moving again. (Note, also that one of the reasons i mention π-calculus is
>   because when you start shipping data between processes you'd like to know
>   that this term really is data and not some nasty little program...)

I wouldn't call the usual representations of data in lambda shoe-horned
(but perhaps you meant the criterion for distinguishing programs from
data, not the notion of data?). Exposing data structures as nothing but
placeholders for the contexts operating on their components, by making
the structure components parameters to yet-to-be-determined continuations,
seems to be as reduced to first-principles as one can get.

It is also close to the old saying that "data are just dumb programs"
(does anyone know who originated that phrase?) - when storage
was tight, programmers couldn't always afford to fill it with dead
code, so they encoded data in (the state of executing) their routines.
When data was separated from real program code, associating data
with the code needed to interpret it was still common. When high-level
languages came along, treating programs as data (via reflective meta-
programming, not higher order functions) remained desirable in some
communities. Procedural abstraction was investigated as an alternative
to abstract data types. Shipping an interpreter to run stored code was
sometimes used to reduce memory footprint.

If your interest is in security of mobile code, I doubt that you want to
distinguish programs and data - "non-program" data which, when
interpreted by otherwise safe-looking code, does nasty things, isn't
much safer than code that does non-safe things directly. Unless you
rule out code which may, depending on the data it operates on, do
unwanted things, which is tricky without restricting expressiveness.

More likely, you want to distinguish different kinds/types of
programs/data, in terms of what using them together can do (in
terms of pi-calculus, you're interested in typing process communication,
restricting access to certain resources, or limiting communication
to certain protocols). In the presence of suitably expressive type
systems, procedural data abstractions need not be any less "safe"
than dead bits interpreted by a separate program. Or if reasoning
by suitable observational equivalences tells you that a piece of code
can't do anything unsafe, does it matter whether that piece is
program or data?

That may be too simplistic for your purposes, but I thought I'd put
in a word for the representation of data structures in lambda.

Claus

Ps. there have been lots of variation of pi-calculus, including
    some targetting more direct programming styles, such as
    the blue calculus (pi-calculus in direct style, Boudol et al).
    But I suspect you are aware of all that.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Brandon S Allbery KF8NH
In reply to this post by Greg Meredith
On 2008 Nov 24, at 17:06, Greg Meredith wrote:
Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out?

Doesn't ST kinda fall outside the pale?  (Well, it is a container of sorts, but a very different from Maybe or [].)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Greg Meredith
Brandon,

i see your point, but how do we sharpen that intuition to a formal characterization?

Best wishes,

--greg

On Mon, Nov 24, 2008 at 10:45 PM, Brandon S. Allbery KF8NH <[hidden email]> wrote:
On 2008 Nov 24, at 17:06, Greg Meredith wrote:
Now, are there references for a theory of monads and take-out options? For example, it seems that all sensible notions of containers have take-out. Can we make the leap and define a container as a monad with a notion of take-out? Has this been done? Are there reasons for not doing? Can we say what conditions are necessary to ensure a notion of take-out?

Doesn't ST kinda fall outside the pale?  (Well, it is a container of sorts, but a very different from Maybe or [].)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Greg Meredith
In reply to this post by Claus Reinke
Claus,

Thanks for your thoughtful response. Let me note that fully abstract semantics for PCF -- a total toy, mind you, just lambda + bools + naturals -- took some 25 years from characterization of the problem to a solution. That would seem to indicate shoe-horning, in my book ;-). Moreover, when i look at proposals to revisit Church versus Parigot encodings for data structures (ala Oliveira's thesis), i think we are still at the very beginnings of an understanding of how data fits into algebraic accounts of computation (such as lambda and π-calculi). 

Obviously, we've come a long way. The relationship between types and pattern-matching, for example, is now heavily exploited and generally a good thing. But, do we really understand what's at work here -- or is this just another 'shut up and calculate' situation, like we have in certain areas of physics. Frankly, i think we are really just starting to understand what types are and how they relate to programs. This really begs fundamental questions. Can we give a compelling type-theoretic account of the separation of program from data?

The existence of such an account has all kinds of implications, too. For example, the current "classification" of notions of quantity (number) is entirely one of history and accident.
  • Naturals
  • Rationals
  • Constructible
  • Algebraic
  • Transcendental
  • Reals
  • Complex
  • Infinitessimal
  • ...
Can we give a type theoretic reconstruction of these notions (of traditional data types) that would unify -- or heaven forbid -- redraw the usual distinctions along lines that make more sense in terms of applications that provide value to users? Conway's ideas of numbers as games is remarkably unifying and captures all numbers in a single elegant data type. Can this (or something like it) be further rationally partitioned to provide better notions of numeric type? Is there a point where such an activity hits a wall and what we thought was data (real numbers; sequences of naturals; ...) are just too close to programs to be well served by data-centric treatments?

Best wishes,

--greg

2008/11/24 Claus Reinke <[hidden email]>
 - i am interested in a first-principles notion of data. Neither lambda

 nor π-calculus come with a criterion for determining which terms represent
 data and which programs. You can shoe-horn in such notions -- and it is
 clear that practical programming relies on such a separation -- but along
 come nice abstractions like generic programming and the boundary starts
 moving again. (Note, also that one of the reasons i mention π-calculus is
 because when you start shipping data between processes you'd like to know
 that this term really is data and not some nasty little program...)

I wouldn't call the usual representations of data in lambda shoe-horned
(but perhaps you meant the criterion for distinguishing programs from
data, not the notion of data?). Exposing data structures as nothing but
placeholders for the contexts operating on their components, by making
the structure components parameters to yet-to-be-determined continuations,
seems to be as reduced to first-principles as one can get.

It is also close to the old saying that "data are just dumb programs"
(does anyone know who originated that phrase?) - when storage
was tight, programmers couldn't always afford to fill it with dead
code, so they encoded data in (the state of executing) their routines.
When data was separated from real program code, associating data
with the code needed to interpret it was still common. When high-level
languages came along, treating programs as data (via reflective meta-
programming, not higher order functions) remained desirable in some
communities. Procedural abstraction was investigated as an alternative
to abstract data types. Shipping an interpreter to run stored code was
sometimes used to reduce memory footprint.

If your interest is in security of mobile code, I doubt that you want to
distinguish programs and data - "non-program" data which, when
interpreted by otherwise safe-looking code, does nasty things, isn't
much safer than code that does non-safe things directly. Unless you
rule out code which may, depending on the data it operates on, do
unwanted things, which is tricky without restricting expressiveness.

More likely, you want to distinguish different kinds/types of
programs/data, in terms of what using them together can do (in
terms of pi-calculus, you're interested in typing process communication,
restricting access to certain resources, or limiting communication
to certain protocols). In the presence of suitably expressive type
systems, procedural data abstractions need not be any less "safe"
than dead bits interpreted by a separate program. Or if reasoning
by suitable observational equivalences tells you that a piece of code
can't do anything unsafe, does it matter whether that piece is
program or data?

That may be too simplistic for your purposes, but I thought I'd put
in a word for the representation of data structures in lambda.

Claus

Ps. there have been lots of variation of pi-calculus, including
  some targetting more direct programming styles, such as
  the blue calculus (pi-calculus in direct style, Boudol et al).
  But I suspect you are aware of all that.




--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

re: monads with take-out options

Greg Meredith
In reply to this post by Greg Meredith
John,

You write:
Yes, you are describing 'co-monads'.

Good catch, but actually, that's too weak. i'm requesting something that is both a monad and a co-monad. That makes it something like a bi-algebra, or a Hopf algebra. This, however, is not the full story. i'm looking for a reference to the full story. Surely, someone has already developed this theory.

Best wishes,

--greg

From: John Meacham <[hidden email]>
Subject: Re: [Haskell-cafe] monads with take-out options
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

On Mon, Nov 24, 2008 at 02:06:33PM -0800, Greg Meredith wrote:
> Now, are there references for a theory of monads and take-out options? For
> example, it seems that all sensible notions of containers have take-out. Can
> we make the leap and define a container as a monad with a notion of
> take-out? Has this been done? Are there reasons for not doing? Can we say
> what conditions are necessary to ensure a notion of take-out?

Yes, you are describing 'co-monads'.

here is an example that a quick web search brought up, and there was a
paper on them and their properties published a while ago
http://www.eyrie.org/~zednenem/2004/hsce/Control.Comonad.html

the duals in that version are

extract - return
duplicate - join
extend  - flip (>>=) (more or less)

       John


--
John Meacham - ⑆repetae.net⑆john⑈

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Greg Meredith
On Mon, 2008-11-24 at 15:06 -0800, Greg Meredith wrote:
> Jonathan,

> Nice! Thanks. In addition to implementations, do we have more
> mathematical accounts? Let me expose more of my motives.
>       * i am interested in a first-principles notion of data.

Hunh.  I have to say I'm not.  The difference between Bool -> alpha and
(alpha, alpha) is not one I've ever felt a need to elaborate.  And I'm
not sure you *could* elaborate it, within a mathematical context ---
which to me means you only work up to isomorphism anyway.

>         Neither lambda nor π-calculus come with a criterion for
>         determining which terms represent data and which programs.

As you know, lambda-calculus was originally designed to provide a
foundation for mathematics in which every mathematical object --- sets,
numbers, function, etc. --- would be a function (a lambda-term) under
the hood.  It was designed to abstract away the distinction between
values and functions, not really to express it.

>         You can shoe-horn in such notions -- and it is clear that
>         practical programming relies on such a separation

What?  `Practical programming' in my experience relies on the readiness
to see functions as first-class values (as near to data as possible).
Implementations want to distinguish them, in various ways --- but then
once you draw that distinction, programmers want to use data structures
like tries, to get your `data structure' implementation for the program
design's `function' types (or some of them...)

As near as I can tell, the distinction between data and code is
fundamentally one of performance, which makes it quite
implementation-dependent.  And, for me, boring.

>         -- but along come nice abstractions like generic programming
>         and the boundary starts moving again.
>         (Note, also that one of the reasons i mention π-calculus is
>         because when you start shipping data between processes you'd
>         like to know that this term really is data and not some nasty
>         little program...)

It's not nice to call my children^Wprograms nasty :)  I think, though,
that the real problem is to distinguish values with finite canonical
forms (which can be communicated to another process in finite time) from
values with infinite canonical forms (which cannot).  The problem then
is defining what a `canonical form' is.  But characterizing the problem
in terms of data vs. code isn't going to help:

  \ b -> if b then 0 else 1

is a perfectly good finite canonical form of type Bool -> Int, while

  repeat 0

is a perfectly good term of type [Int] (a data type!) with no finite
canonical form (not even a finite normal form).

I'm sure this fails to engage your point, but perhaps it might clarify
some points you hadn't considered.

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Jules Bean
In reply to this post by Greg Meredith
Greg Meredith wrote:

> Haskellians,
>
> Some monads come with take-out options, e.g.
>
>     * List
>     * Set
>
> In the sense that if unit : A -> List A is given by unit a = [a], then
> taking the head of a list can be used to retrieve values from inside the
> monad.
>
> Some monads do not come with take-out options, IO being a notorious example.
>
> Some monads, like Maybe, sit on the fence about take-out. They'll
> provide it when it's available.

To amplify other people's comments:

List A is just as on the fence as Maybe. "[]" plays the role of "Nothing".

Some monads require that you put something in, before you take anything
out [r -> a, s -> (a,s), known to their friends as reader and state]

Error is similar to Maybe, but with a more informative Nothing.

Most monads provide some kind of

runM :: ## -> m a -> ## a

where the ## are meta-syntax, indicating that you might need to pass
something in, and you might get something slightly 'funny' out.
Something based upon 'a' but not entirely 'a'.

The taxonomy of monads is pretty much expressed in the types of these
'run' functions, I think.

Jules
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: monads with take-out options

Bugzilla from jonathanccast@fastmail.fm
On Wed, 2008-11-26 at 19:09 +0000, Jules Bean wrote:

> Greg Meredith wrote:
> > Haskellians,
> >
> > Some monads come with take-out options, e.g.
> >
> >     * List
> >     * Set
> >
> > In the sense that if unit : A -> List A is given by unit a = [a], then
> > taking the head of a list can be used to retrieve values from inside the
> > monad.
> >
> > Some monads do not come with take-out options, IO being a notorious example.
> >
> > Some monads, like Maybe, sit on the fence about take-out. They'll
> > provide it when it's available.
>
> To amplify other people's comments:
>
> List A is just as on the fence as Maybe. "[]" plays the role of "Nothing".
>
> Some monads require that you put something in, before you take anything
> out [r -> a, s -> (a,s), known to their friends as reader and state]
>
> Error is similar to Maybe, but with a more informative Nothing.
>
> Most monads provide some kind of
>
> runM :: ## -> m a -> ## a

More precisely,

    runM :: f (m a) -> g a

Where f and g are usually functors.

Maybe, of course, has the nice property that g = m.

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe