How is join defined is not specified, but it has to respect monad laws.

Haskell is not a point-free language, so you cannot transparently overload the . operator and so work in arbitrary Kleisli categories, you must use bind. (The alternative would be to overload function application!)

The OP responded as such probably because of your (by layperson standards, provocative) title.

But thank you for providing context to the discussion. Having understood a bit more of Moggi's work, I really appreciate it.

I'm afraid I'll have to disagree with your assertion that (to paraphrase) monads are a mere stylistic device. Far from it: using category theory to provide semantics is every bit as radical as using category theory instead of set theory to account for mathematical objects. And that is very radical indeed.

You state that Moggi was not addressing the problem of how to "represent side effects in denotational semantics". I suggest you read his papers. He explicitly lists denotational semantics as one of the approaches whose failures he attempts to remedy. Read the papers. Alas, I don't have the mathematical chops to make judgements about this sort of thing, but I've done enough research to understand that Moggi was after something far more deep than mere "organize and modularize these representations", as you put it. Again, read his papers; his goal was to produce a lambda of calculations. He was quite explicit that he was addressing exactly those issues that you claim he was not addressing!

It's not a question of whether monads are uniquely suitable to represent IO etc.; I doubt any of the experts would endorse such an opinion.

I frankly don't understand where you get the idea of "sweeping semantics under the rug"; Moggi's entire point was to provide good semantics, using Category Theory. Presumably you mean that eliminating objects is a Bad Idea. All I can say is, read the literature. Category theory is quite explicit: objects don't matter. That's the genius of it, and if it seems a "mockery", maybe you should think a little harder.

-g

Ok, so the idea is that you have a text, which is pure syntax (and lexicon, I suppose), and you provide semantics by mapping the constituent elements of the syntax to elements of some semantic domain. The fundamental presupposition for mathematical notation is "referential transparency", which is a very direct metaphor: when you look at a symbol like '2' (I mean literally the arrangement of black ink against white background), you know (because of social convention) that it is intended to "denote" (=mean) the integer "two": metaphorically, the symbol is transparent, so you can see through it to discern it's "meaning". Now if you add terms that do not have this clear interpretation (e.g "print", "read", etc.), you break the semantic integrity of the text. You (the human reader) can no longer reason about it, because you don't know what e.g. "getChar" means. Well, ok, you know it means "get a char from the user", but you don't know its denotation - the meaning of "meaning" tends to get lost in all the abstarction. You may know "getChar" denotes a character, but you don't know which one. This is true of any term/expression whose denotation cannot be determined by (human) inspection of the text. So the inclusion of any such term subverts the meaning of the text. Or at least destabilizes it.

So by "disruption of the semantic integrity of the text", I mean the compromising of referential integrity. Any ink-on-paper mathematical text has referential integrity; "getChar" would be preposterous in a mathematical proof. But in a program text, you can have such expressions, and their presence entails the disruption of the semantic integrity you would have in an ink-on-paper mathematical text.

Until I find a better term, I will call such terms "referentially opaque", since the reader cannot "see through" them to look at their meaning. In practice, this means non-deterministic terms, like "random", "getChar", "putChar", etc. You may think the last is deterministic, but in fact it is merely reliable. Any random gamma ray can introduce error into the output of a program, so you may say "putChar 'x'", but you cannot guarantee that the output will in fact be 'x', since it goes through a RealWorld mechanism, which is unreliable by definition.

In sum, terms that are not referentially transparent compromise the integrity (reliabilty) of the program text, and "class of opaque terms" is just a way of thinking about all such terms as a class.

Hope that helps,

-gregg

There is no sweeping the semantics under the rug. In particular, if the last sentence of your post was true it would make a mockery of the entire field of denotational semantics and of Moggi's contributions in particular. Luckily, that sentence and others like it have no relation to reality. The entire purpose of denotational semantics is to explain such things not to hide them away.

He gives the following examples of "notion of computation": partiality, non-determinism, side-effects, exceptions, continuations, and interactive input/output. What these "notions" have in common is disruption of the semantic integrity of a program text. They violate the principle of referential transparency, rendering the text literally uninterpretable to the human reader. So "notions of computation" effectively means the class of opaque terms in programming languages.