On Wed, Jan 27, 2010 at 11:39 AM, Jochem Berndsen wrote:

...

Now, here's the question: Is is correct to say that [3, 5, 8] is a monad?

In what sense would this be a monad? I don't quite get your question.

I think the question is this: if m is a monad, then what do you call a thing of type m Int, or m Whatever. Luke

I don't like this bias toward singling out Monad among all of the type classes, thereby perpetuating the misleading mystique surrounding Monad. If you're going to call [3,5,8] "a monadic value", then please give equal time to other type classes by also calling [3,5,8] "a functorial value" ("functorific"?), "an applicative value", "a monoidal value", "a foldable value" ("foldalicious"?), "a traversable value", "a numeric value" (see the applicative-numbers package), etc. Similarly when referring to values of other types that happen to be monads as well as other type classes. - Conal On Wed, Jan 27, 2010 at 12:17 PM, Jochem Berndsen wrote:

Luke Palmer wrote:

...

On Wed, Jan 27, 2010 at 11:39 AM, Jochem Berndsen wrote:

...

...

Now, here's the question: Is is correct to say that [3, 5, 8] is a monad? In what sense would this be a monad? I don't quite get your question.

I think the question is this: if m is a monad, then what do you call a thing of type m Int, or m Whatever.

Ah yes, I see. It's probably the most common to call this a "monadic value" or "monadic action". As Daniel pointed out, the type constructor itself is called a "monad" (e.g., Maybe).

Jochem

-- Jochem Berndsen | jochem@functor.nl _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi On 27 Jan 2010, at 20:14, Luke Palmer wrote:

On Wed, Jan 27, 2010 at 11:39 AM, Jochem Berndsen wrote:

...

...

Now, here's the question: Is is correct to say that [3, 5, 8] is a monad?

In what sense would this be a monad? I don't quite get your question.

I think the question is this: if m is a monad, then what do you call a thing of type m Int, or m Whatever.

It has been known to call such things 'computations', as opposed to 'values', and even to separate the categories of types and expressions which deliver the two. I think that's a useful separation: I wish return (embedding values in computations) were silent, and thunk (embedding computations in values) made more noise. Cheers Conor

Luke _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 27 Jan 2010, at 22:02, Daniel Fischer wrote:

Am Mittwoch 27 Januar 2010 22:50:35 schrieb Conor McBride:

...

It has been known to call such things 'computations', as opposed to 'values', and even to separate the categories of types and expressions which deliver the two.

As usual, that only works part of the time. [1,4,15,3,7] is not a computation, it's a list of numbers. A plain and simple everyday value.

Yes, the separation is not clear in Haskell. (I consider this unfortunate.) I was thinking of Paul Levy's call-by-push-value calculus, where the distinction is clear, but perhaps not as fluid as one might like. Int list values and nondeterministic int computations are conceptually different, even if they have isomorphic representations. Identifying their types has its downsides. Cheers Conor

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Alexander Solla wrote:

On Jan 27, 2010, at 4:57 PM, Conor McBride wrote:

...

Yes, the separation is not clear in Haskell. (I consider this unfortunate.) I was thinking of Paul Levy's call-by-push-value calculus, where the distinction is clear, but perhaps not as fluid as one might like.

What, exactly, is the supposed difference between a value and a computation? Please remember that computations can and very often do "return" computations as results. Please remember that in order for a function to be computed for a value, binding and computation must occur. And that for every value computed, a computation must occur, even if it is "just" under identity the identity function.

The difference is ontological. To pull in some category theory ---only because it helps make the distinction explicit--- there's a big difference between a morphism |A->B| and an exponential object |B^A|. What's the difference? Well, one is a morphism and the other is an object; they're simply different sorts of things, and it's a syntactic error to put one in the place of the other. In Cartesian Closed Categories (and similar) it so happens that the category "has exponentials", i.e. for every morphism |f:A->B| there exists an exponential object |o:B^A|. Because of the has-exponentials law, we know that in a CCC for every |f| there's an |o| and for every (exponential) |o| there's an |f|; but that does not mean that |f| and |o| are the *same* thing, it merely means we can conceptually convert between them. So what has any of this to do with Haskell? For the non category theorists in the audience: morphisms capture the notion of functions as procedures; that is, morphisms *do* things (or: are actions). Exponential objects capture the notion of functions as values/arguments; that is, objects *are* things. Down in the compiler we make the same exact distinction when distinguishing code or code pointers (morphisms) from closures (objects). In functional languages there are invisible coercions between functions-as-procedures and functions-as-values. The problem, as it were, is that the coercion is invisible. Why is this a problem? Most of the time it isn't; it's part of what makes functional programming so clean and elegant. Consider the identity monad. It's a simple monad, it's exactly the same thing as using direct values except with a newtype wrapper. Since it's exactly the same, why not try writing a program using |Id| everywhere instead of using the direct style. If you try this you'll see just how much invisible coercion is going on. That's part of the reason why it's sugared away. But some of the times you want or need to be explicit about the coercions (or conversely, want to change which coercions are implicit). Consider for instance the problem of having distinct functions |map| vs |mapM| or any other |foo| vs |fooM|. The reason for this proliferation is that, syntactically, we must write different code depending on whether we're using the invisible coercions of direct values, vs whether we're making the coercions explicit by using some monad (or applicative, or whatever). Haskell and similar languages choose a particular set of coercions to make invisible and implicit. Currying, uncurrying, application, etc. But there's nothing sacred about choosing to make those particular coercions invisible instead of choosing a different set of coercions to sugar away. -- Live well, ~wren

Daniel Fischer writes:

...

It has been known to call such things 'computations',

I think "actions" has been used, too, but perhaps mostly for things in IO and similar monads?

...

as opposed to 'values', and even to separate the categories of types and expressions which deliver the two.

As usual, that only works part of the time. [1,4,15,3,7] is not a computation, it's a list of numbers. A plain and simple everyday value.

But isn't a value of (IO String) equally plain and simple? I think I prefer (as somebody suggested) "monadic value", so that (if you want to stress this aspect of its use) the list is a monadic Int value in the [] monad, while getLine is a monadic String value in the IO monad, and so on. Maybe. -k -- If I haven't seen further, it is by standing in the footprints of giants

Quoth Daniel Fischer ,

Am Donnerstag 28 Januar 2010 09:14:38 schrieb Ketil Malde:

...

Daniel Fischer writes:

...

As usual, that only works part of the time. [1,4,15,3,7] is not a computation, it's a list of numbers. A plain and simple everyday value.

But isn't a value of (IO String) equally plain and simple?

Sure, but saying a value of type IO String is "a computation (in the IO monad) returning a String" makes more sense to me than saying [True,False,True] is "a computation (in the [] monad) returning a Bool".

For sure, and in general when people speak of monads they're really talking about IO, true? If that's disappointing, maybe it would help to have a word for it, maybe `IO String' is an "irreduceable monadic value" or something. Donn

On Sat, Jan 30, 2010 at 1:24 AM, Conal Elliott wrote:

I call it "an m" or (more specifically) "an Int m" or "a list of Int". For instance, "a list" or "an Int list" or "a list of Int". - Conal

On Wed, Jan 27, 2010 at 12:14 PM, Luke Palmer wrote:

...

On Wed, Jan 27, 2010 at 11:39 AM, Jochem Berndsen wrote:

...

...

Now, here's the question: Is is correct to say that [3, 5, 8] is a monad?

In what sense would this be a monad? I don't quite get your question.

I think the question is this: if m is a monad, then what do you call a thing of type m Int, or m Whatever.

Luke

Conal's is the most sensible approach - "what do you call it" amounts to "what sort of a thing is it", and the best we can say in that respect is "er, its a thing of type m Whatever". (My preference, if maximal explicitness is needed, is to say "it's a token of its type"; some say "term of type m Whatever".) Trying to classify such a thing as "value", "object", "computation", "reduction" etc. inevitably (and necessarily) leads to tail-chasing since those notions are all essentially equivalent. Plus they miss the essential point, which is the typing. Original poster would probably find Martin-Lof's philosophically-tinged writings very good on this - clear, reasonably simple, and revelatory, if you've never closely looked at intuitionistic logic before. Truth of a proposition, evidence of a judgment, validity of a proofhttp://www.jstor.org/pss/20116466is especially readable, as is On the meanings of the Logical Constants and the Justifications of the Logical Laws http://www.hf.uio.no/ifikk/filosofi/njpl/vol1no1/meaning/meaning.html. Presents a completely new (to me) way of thinking about "what is it, really?" questions about computation, monads, etc., i.e. ask not "what is it?" but "how do you know?" or even "how do you make it?" The Stanford article on types and tokenshttp://plato.stanford.edu/entries/types-tokens/is also very enlightening in this respect. -g