I thought a pure value was being returned from the monad. :) On Mon, Aug 5, 2013 at 10:32 PM, Christian Sternagel wrote:

Dear Jurriën.

personally, I like "lift" (which is of course already occupied in Haskell), since an arbitrary value is "lifted" into a monad. (The literature sometimes uses "unit".)

cheers

chris

On 08/06/2013 02:14 PM, J. Stutterheim wrote:

...

Dear Cafe,

Suppose we now have the opportunity to change the name of the `return` function in Monad, what would be a "better" name for it? (for some definition of better)

N.B. I am _not_ proposing that we actually change the name of `return`. I do currently have the opportunity to pick names for common functions in a non-Haskell related project, so I was wondering if there perhaps is a better name for `return`.

- Jurriën ______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

-- -- Regards, KC

Hi Tarik, Could you motivate the choice for these names? Thanks! On 6 Aug 2013, at 08:14, Tarik ÖZKANLI wrote:

next, carry, feed, roll

On 6 August 2013 08:37, KC wrote: I thought a pure value was being returned from the monad. :)

On Mon, Aug 5, 2013 at 10:32 PM, Christian Sternagel wrote: Dear Jurriën.

personally, I like "lift" (which is of course already occupied in Haskell), since an arbitrary value is "lifted" into a monad. (The literature sometimes uses "unit".)

cheers

chris

On 08/06/2013 02:14 PM, J. Stutterheim wrote: Dear Cafe,

Suppose we now have the opportunity to change the name of the `return` function in Monad, what would be a "better" name for it? (for some definition of better)

N.B. I am _not_ proposing that we actually change the name of `return`. I do currently have the opportunity to pick names for common functions in a non-Haskell related project, so I was wondering if there perhaps is a better name for `return`.

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

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

-- -- Regards, KC

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

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

On 08/06/2013 04:30 PM, J. Stutterheim wrote:

Thanks Chris. Yes, I like lift as well, because I find it a rather intuitive name. Unfortunately, as you say, it is already a commonly used name as well, which might make it slightly confusing.

When I hear `unit` I immediately think about generic programming, not so much about monads. Can you perhaps explain the intuition behind `unit` as an alternative to `return` in the context of monads? Probably because of the monad laws, where `return` is a "unit" (in the mathematical sense) for the `bind` operation. - chris

- Jurriën

On 6 Aug 2013, at 07:32, Christian Sternagel wrote:

...

Dear Jurriën.

personally, I like "lift" (which is of course already occupied in Haskell), since an arbitrary value is "lifted" into a monad. (The literature sometimes uses "unit".)

cheers

chris

On 08/06/2013 02:14 PM, J. Stutterheim wrote:

...

Dear Cafe,

Suppose we now have the opportunity to change the name of the `return` function in Monad, what would be a "better" name for it? (for some definition of better)

N.B. I am _not_ proposing that we actually change the name of `return`. I do currently have the opportunity to pick names for common functions in a non-Haskell related project, so I was wondering if there perhaps is a better name for `return`.

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

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

I have to admit that I am a bit torn about using `pure`. On the one hand, if you actually have a pure value, it feels pretty intuitive to me. But what about pure (putStrLn "Hi") `putStrLn "Hi"` is not a pure value... Or is there another way to interpret the word pure in this context? As for Applicative, I can add (and have added) the Applicative constraint in the Monad definition for my project, so I will also have to write an Applicative instance for my monads. - Jurriën On 6 Aug 2013, at 09:50, Erik Hesselink wrote:

What about `pure`? It's already used in applicative, and has the motivation that it's embedding a pure value in some context. Since I don't know the details of your project, I don't know if you need two names (one for the applicative version, and one for the monadic version).

Erik

On Tue, Aug 6, 2013 at 7:14 AM, J. Stutterheim wrote:

...

Dear Cafe,

Suppose we now have the opportunity to change the name of the `return` function in Monad, what would be a "better" name for it? (for some definition of better)

N.B. I am _not_ proposing that we actually change the name of `return`. I do currently have the opportunity to pick names for common functions in a non-Haskell related project, so I was wondering if there perhaps is a better name for `return`.

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

What about 'inject'? On 6 August 2013 09:09, Karol Samborski wrote:

What about 'pack'?

Best, Karol

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

It is a pure value in the context of the outer monad (the one you wrap it in). I'd say pure is still appropriate. On Aug 6, 2013 10:14 AM, "Tom Ellis" < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

On Tue, Aug 06, 2013 at 10:03:04AM +0200, J. Stutterheim wrote:

...

`putStrLn "Hi"` is not a pure value...

Why not?

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

But IO actions *are* pure values. What side effects do they have? None! You can do whatever you want with them with no harmful effects in any Haskell expression. They only special thing about them is that they have a run function that is not itself provided in Haskell. The run function is actually not legal to expose in pure Haskell. Even if it were exposed, *that function* would be the impure thing, not the IO actions you apply it to. (This is why GHC has unsafePerformIO and not UnsafeIO). - Jake On Aug 6, 2013 5:29 AM, "J. Stutterheim" wrote:

That argument makes sense, although I find it a bit counter-intuitive still. If I saw the function `pure` for the first time, my first impression (however wrong it may be) would be that it takes a pure value (regardless of context) and does something with it. Applying `pure` to an IO operation goes against that intuition.

Looking at the type of `return :: a -> m a", there are several slightly more intuitive (to me) options in this discussion already:

lift: the value `a` is lifted into the monad `m` pack: the value `a` is packed into the monad `m` wrap: the value `a` is wrapped in the monad `m` inject: the value `a` is injected into the monad `m` promote: the value `a` is promoted to a monad `m a`

On 6 Aug 2013, at 10:16, Tobias Dammers wrote:

...

It is a pure value in the context of the outer monad (the one you wrap it in). I'd say pure is still appropriate.

On Aug 6, 2013 10:14 AM, "Tom Ellis" < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote: On Tue, Aug 06, 2013 at 10:03:04AM +0200, J. Stutterheim wrote:

...

`putStrLn "Hi"` is not a pure value...

Why not?

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

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

On Tue, Aug 06, 2013 at 04:26:05PM +0200, Jerzy Karczmarczuk wrote:

1. First, it is not true that you can do with, say, (printStr "Ho!" ) whatever you want. In fact, you can do almost nothing with it. You can transport it "as such", and you can use it as the argument of (>>=).

I don't think this argument holds much water. You can do even less with ().

2. This is the only way you can evaluate your "pure value", and because of the monadic chaining, you cannot do it twice, you cannot "re-evaluate" it.

I'm sure there is a sense in which this is true, but I'm not seeing it. How would you describe what's going on here? twice :: IO () -> IO () twice x = x >> x main = twice $ putStrLn "foo" I would call that evaluating x twice (incidentally creating two separate evaluations of one pure action description), but I'd like to better see your perspective here. Regarding this issue generally, I feel like everyone's climbed on their particular war horses when someone sounded the PURITY trumpet, when *I don't think this is the kind of purity Applicative is talking about* - different things can be pure in different ways.

On 2013-08-07 22:38, Joe Quinn wrote:

On 8/7/2013 11:00 AM, David Thomas wrote:

...

twice :: IO () -> IO () twice x = x >> x

I would call that evaluating x twice (incidentally creating two separate evaluations of one pure action description), but I'd like to better see your perspective here.

x is only evaluated once, but /executed/ twice. For IO, that means magic. For other types, it means different things. For Identity, twice = id!

Your point being? x is the same thing regardless of how many times you run it.

On 08/08/2013 01:19 AM, Jerzy Karczmarczuk wrote:

Bardur Arantsson comments the comment of Joe Quinn:

...

...

...

On 8/7/2013 11:00 AM, David Thomas wrote:

...

...

twice :: IO () -> IO () twice x = x >> x

I would call that evaluating x twice (incidentally creating two separate evaluations of one pure action description), but I'd like to better see your perspective here.

x is only evaluated once, but/executed/ twice. For IO, that means magic. For other types, it means different things. For Identity, twice = id!

Your point being? x is the same thing regardless of how many times you run it.

What do you mean by "the same thing"? You cannot compare 'them' in any reasonable sense. ...

http://en.wikipedia.org/wiki/Identity_of_indiscernibles (He is reasoning _about_ the language and not _within_ the language because Haskell does not support very powerful reasoning internally.)

... You make the distinction between "evaluate",

Which essentially means applying reduction rules to an expression until the result is a value.

and "execute" or "run", etc. This is not functional.

How would you know?

Your program doesn't "run" anything, it applies (>>=) (or equivalent) to an IO (...) object. This is the only "practical evaluation" of it, otherwise it can be passed (or duplicated as above). But you cannot apply "bind" twice to the same instance of it (in fact, as I said above, "the same instance" is a bit suspicious concept...). ...

Indeed, but you didn't say that above.

The "running" or "execution" takes place outside of your program. In such a way Richard O'Keefe and I converge... That's why I say that the concept of purity is meaningless in the discussed context.

Not meaningless, but redundant. The point of having a purely functional programming language is to have reasoning based on purity be universally applicable.

It is a kind of counterfeit notion, inherited from "pure functions" to something which belongs to two different worlds. ...

'putStr "c"' is a pure value. On the other hand: 'unsafePerformIO (putStr "c")' is not a pure value. (But this expression does not exist in standard Haskell. unsafePerformIO "unquotes" the action. You may be confusing the "quoted" and "unquoted" versions.)

I have the impression that a nice part of our dispute comes from the fact that despite our ambitions, and a decent /technical/ level of understanding of what we are talking about, most of us are (and I am one of the worst...) -- -- pitiful philosophers... Really bad... Confusing the contents and the function/role of the entities, using ambiguous definitions (and confounding objects with their definitions), et j'en passe. Sigh. I decided to reread some philosophical texts, and I suggest one for your evening reading. "Indiscrete Thoughts" by Gian-Carlo Rota, published by Birkhäuser in 1997. Available on the Web. Rota was an active *mathematician* and teacher, and the sense of mathematical constructs was very important for him. It is a very refreshing book, you won't be disappointed. (It contains also some personal views of Rota on his fellows mathematicians. And the analysis of the difference between characters who are "problem solvers", as contrasted with "theoreticians"... Rota was a strong personality, full of "obsessions", and his ideas on the soundness of formal thinking may not convince you, but you should find them interesting. And you will find inside that for Rota the term "should" is very important, even if it impossible to define...) Many thanks to Olivier Danvy, who recommended me this book! Jerzy Karczmarczuk Caen, France.

Kim-Ee Yeoh comments my reading suggestion:

"Indiscrete Thoughts" by Gian-Carlo Rota, published by Birkhäuser in 1997. Available on the Web. [I forgot where]

I'm rather fond of Rota's two volumes of musings. For the purpose of furthering the quality of philosophizing, would it not be better served citing the relevant chapters, if not the actual page numbers?

As you took note, the book covers a swathe of topics.

Shall I also give the line numbers, Kim-Ee? The book of Rota is divided into parts and chapters, with titles. It is not so difficult to find quickly that something may (or not) interest you. What is a "relevant" chapter in a collection of philosophical essays? You might skip the "biographies" of some mathematicians, with some unpleasant fragments, if you are not interested. I liked a few others. Part II, Ch. VII: "The Pernicious Influence of Mathematics Upon Philosophy" is an inspired attack addressed at the "analytical philosophers" who felt really offended! (This is a reprint from the Journal of Metaphysics, published also in the book "18 Unconventional Essays on the Nature of Mathematics", Springer, ed. by Reuben Hersh. I also recommend it [also on the Web], it is plenty of serious wisdom, although sometimes hard to read.) This chapter deals with the non-philosophical essence of logic, with the "philosophical vacuity" of formal definitions. Very inspiring. For Rota the question of IDENTITY is more important than that of EXISTENCE. The chapter XII: "Syntax, Semantics, and the Problem of the Identity of Mathematical Items" (p. 151) begins his presentation of the subject, which continues later. Rota exposes some reasoning based on his favourite philosophical topic, the phenomenology, continuing previous sections. This may not convince you (e.g. if you are an orthodox materialist...), but you might learn something. The chapter about /Fundierung/ (XV, p. 172) in which Rota fights against the reductionism, may give you a headache. But you should survive. Anyway, /a ciascuno il suo/. Jerzy K.

On Thu, Aug 08, 2013 at 01:19:27AM +0200, Jerzy Karczmarczuk wrote:

Bardur Arantsson comments the comment of Joe Quinn:

...

...

...

On 8/7/2013 11:00 AM, David Thomas wrote:

...

...

twice :: IO () -> IO () twice x = x >> x

I would call that evaluating x twice (incidentally creating two separate evaluations of one pure action description), but I'd like to better see your perspective here.

x is only evaluated once, but/executed/ twice. For IO, that means magic. For other types, it means different things. For Identity, twice = id!

Your point being? x is the same thing regardless of how many times you run it.

What do you mean by "the same thing"? You cannot compare 'them' in any reasonable sense.

This, the impossibility to check putStr "c" == putStr "c", is btw, a refutation of the claim by Tom Ellis that you can do even less with (). The void object is an instance of the Eq and Ord classes. And of Show as well.

If I were writing a Haskell compiler I could certainly define 'IO' to be a datatype that would allow me to compare 'putStr "c"' to itself. The comparison could not be of operational equivalence, but it would still be possible to compare values in IO in a reasonable sense. Tom

On Thu, Aug 08, 2013 at 11:38:08AM +0200, Jerzy Karczmarczuk wrote:

Tom Ellis:

...

If I were writing a Haskell compiler I could certainly define 'IO' to be a datatype that would allow me to compare 'putStr "c"' to itself. The comparison could not be of operational equivalence, but it would still be possible to compare values in IO in a reasonable sense.

Would you add to all this: getLine == getLine etc.?

Good luck!

I suspect that you would have to establish also the equality relation between functions and between infinite streams. And you would end as Giordano Bruno and Jeanne d'Arc. But for different reasons.

Not at all. One could simply implement IO as a free monad, to take one example. Tom

On Thu, Aug 08, 2013 at 08:41:25AM -0400, Jake McArthur wrote:

I don't know what the denotation for this would be, but I can't think of any reasonable ones for which I can write (==) to respect the denotation. For example, is "set A, then set B" equal to "set B, then set A"? [...]

I'm a bit lost as to what's actually being discussed in this thread, but Jerzy seemed to suggest that the "impurity" of IO was somehow related to it not supporting very many operations. I was trying to point out that this doesn't seem to be a good characterisation. I do not, however, have a good candidate for the definition of "impure". Tom

On Thu, Aug 08, 2013 at 03:38:41PM +0200, Jerzy Karczmarczuk wrote:

...

One could simply implement IO as a free monad Interesting. I wonder how.

See [1] for an explanation of free monads in general. For IO in particular, define a functor data IOF a = GetChar (Char -> a) | PutChar Char a | ... with constructors for all elementary IO operations. Then take type IO a = Free IOF a and define getChar :: IO Char getChar = liftF (GetChar id) putChar :: Char -> IO () putChar c = liftF (PutChar c ()) etc.. I make no claims about the performance of a runtime system based on suhc a representation! Tom

On Thu, Aug 08, 2013 at 05:23:50PM +0100, Oliver Charles wrote:

On 08/08/2013 05:05 PM, Tom Ellis wrote:

...

On Thu, Aug 08, 2013 at 03:38:41PM +0200, Jerzy Karczmarczuk wrote:

...

...

One could simply implement IO as a free monad Interesting. I wonder how.

See [1] for an explanation of free monads in general

You're lacking a matching definition of [1] :)

Ah thank you! [1] http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.htm...

On Thu, Aug 08, 2013 at 06:25:12PM +0200, Daniel Trstenjak wrote:

...

See [1] for an explanation of free monads in general. For IO in particular, define a functor

data IOF a = GetChar (Char -> a) | PutChar Char a | ...

with constructors for all elementary IO operations.

But how should this work if the user adds an IO operation, e.g by wrapping a C function?

Wrapping a C function could perhaps be provided by something like data IOF a = ... | forall i o. Foreign String i (o -> a) | ... csin :: Double -> IO Double csin x = liftF (Foreign "math.h sin" x id) Tom

On Thu, Aug 8, 2013 at 11:05 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

On Thu, Aug 08, 2013 at 03:38:41PM +0200, Jerzy Karczmarczuk wrote:

...

...

One could simply implement IO as a free monad Interesting. I wonder how.

See [1] for an explanation of free monads in general. For IO in particular, define a functor

data IOF a = GetChar (Char -> a) | PutChar Char a | ...

with constructors for all elementary IO operations.

If I understand correctly, you're proposing equality of (IO a) based on the AST of imperatives, similar to what comes out of GCC's front-end for C [1]. In what way is this syntactical equality "reasonable"? Useful perhaps for detecting C&P coding from befuddled undergrads? [1] http://digitocero.com/es/blog/exportar-y-visualizar-el-arbol-sintactico-abst... -- Kim-Ee

Ah! It seems that my wording was ambiguous. All I was trying to say is that there is nothing you can do with an IO action which will cause an otherwise pure expression to exhibit side effects during evaluation, *not* that an IO action is observable in pure code or that they are arbitrarily manipulable. On Aug 8, 2013 9:39 AM, "Jerzy Karczmarczuk" wrote:

I am sorry for having mixed-up arguments (but who throws the first stone?...)

Jerzy seemed to suggest that the "impurity" of IO was somehow related to it not supporting very many operations.

No, not really. I added

First, it is not true that you can do with, say, (printStr "Ho!" ) whatever you want. In fact, you can do almost nothing with it. You can transport it "as such", and you can use it as the argument of (>>=).

after the message of Jake McA.

*You can do whatever you want with them* with no harmful effects in any Haskell expression.

This was an additional layer of bikeshedding, not exactly about purity. Or, just a bit: the ONLY "real" operation on an action, i.e. (>>=) produces side-effects... Other don't, but --

Again, here my point is that calling "pure" an entity which is opaque and inert, is meaningless (or "redundant" if you wish...), this was all.

Jerzy K.

PS. Tom Ellis:

One could simply implement IO as a free monad

Interesting. I wonder how.

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

I bet you can find an abundance of C programmers who think that "strcmp" is an intuitive name for string comparison (rather than compression, say).

But at least, 'strcmp' is not a common English language term, to have acquired some unintentional 'intuition' by being familiar with it even in our daily life. The Haskell terms, say, 'return' and 'lift', on the other hand, do have usage in common English, so even a person with _no_ programming background would have acquired some unintentional 'intuition' by being familiar with them. And in that light, _for_me_, 'lift' is more _intuitive_ than 'return' or 'pure'. It seems, to me, like the thing being 'lifted' from a given world into a more 'abstract' world. Of course, I recall reading somewhere: a poet is a person who uses the different words to mean the same thing, while a mathematician is a person who ascribes more meanings to the same word. Haskell, being originated from _mathy_ people, we do get to _enjoy_ this effect. Having said this, it has actually helped me build a different type of 'intuition' for words and I do enjoy it. Thanks and regards, -Damodar Kulkarni On Wed, Aug 7, 2013 at 6:40 AM, Richard A. O'Keefe wrote:

On 6/08/2013, at 9:28 PM, J. Stutterheim wrote:

...

That argument makes sense, although I find it a bit counter-intuitive still.

In discussions like this, I have never been able to discover any meaning for "intuitive" other than "familiar". Applying "pure" to an IO operation doesn't go against *my* intuition because Haskell has *trained* my intuition to see 'putStrLn "Hi"' as a pure value; it's not the thing itself that has effects, but its interpretation by an outer engine, just as my magnetic card key has by itself no power to open doors, but the magnetic reader that looks at the card _does_. I don't attribute agency to the card! I'm not arguing that my intuition is _right_, only that it is _different_.

In particular, for anyone who has much experience with Haskell, "return" is almost the only name that could possibly be intuitive because that _is_ the name that is familiar. Haskell programmers who've got used to Applicative will also find "pure" intuitive, *because it is familiar*.

I bet you can find an abundance of C programmers who think that "strcmp" is an intuitive name for string comparison (rather than compression, say).

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

One of the surprising things of Haskell is how little effort is done in order to confer meaning to the names. That happens also in the case of the mathematical language. Often they have a single letter. The reason is that their meaning is completely defined by their signature and their properties. And this is possible because Haskell has a strong and polymorphic type system. In other languages, either this is not possible or the libraries have little polymorphism, so the names can be more concrete. return :: (Monad m) => a -> m a The meaning is in the signature. We can opt between keeping the name as a short mnemonic of the signature or else we can adhere to the C tradition: return === monad_m___a__m_a or the Java Tradition return =MonadFactory.liftSomethingSometimesPureButInSomeCasesTheResultIsAlsoPure 2013/8/7 Richard A. O'Keefe

On 7/08/2013, at 2:10 PM, damodar kulkarni wrote:

...

I bet you can find an abundance of C programmers who think that "strcmp" is an intuitive name for string comparison (rather than compression, say).

But at least, 'strcmp' is not a common English language term, to have acquired some unintentional 'intuition' by being familiar with it even in our daily life. The Haskell terms, say, 'return' and 'lift', on the other hand, do have usage in common English, so even a person with _no_ programming background would have acquired some unintentional 'intuition' by being familiar with them.

"Lift" is - a brand of soft drink, the thing Americans call an elevator, a thing put in your shoes seem taller, and a free ride, amongst other things. As a verb, it can mean to kick something.

To find "lift" intuitive, you have to be familiar with the *mathematical* idiom of "lifting" a value from one space to another via some sort of injection. Fair enough, but this *still* counts as an example of "intuitive = familiar", because this is *not* a sense of "lift" that is familiar to undergraduate and masters computing students unless they have taken rather more mathematics papers than most of them have.

If you're familiar with *English* rather than, say, the C family of programming languages, "return" isn't _that_ bad, there is certainly nothing about the word that suggests providing a value. I once tried to propose a C-style 'return' statement to some people who were designing a programming language, before I or they had ever heard of C, and they flatly rejected it. Months later I found out that this was because they were looking for something that did not just resume the caller but also provided a value, and when I protested that that's exactly what 'return' did in the languages I proposed stealing from, they -- being familiar with Fortran -- said that it had never occurred to them that 'return' could have anything to with providing a value.

"It is intuitive" has no other discernable meaning than "*I* am familiar with it, or something very much like it."

_That's_ the point I want to make. *Whatever* anyone uses for Haskell's "return", many people are bound to find it unintuitive. Choose a name on any grounds but that.

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

-- Alberto.

On 8/08/2013, at 2:09 AM, damodar kulkarni wrote:

Thanks for pointing this out, I was not able to point my thoughts in this direction.

But I still have a doubt: if my familiarity doesn't come in the form of some "analogy", then my acquired intuition about "it" would be of little use. In fact, it may well be misleading. Am I correct?

Very much so. This is why I despise, detest, and loathe as abominations programming languages in which string concatenation is written "+". (If you want a binary operation which is associative and has an identity but doesn't commute, the product lies ready to hand, and the repeated product (exponentiation) is actually _useful_ for strings. It's still better to use a non-arithmetic operator, as PL/I, Fortran, Ada, and Haskell do.)

If so, the best we can hope is the name-giver to describe, as explicitly as possible, the "analogy" (sort of a thought process) he/she had had in his/her mind while giving a particular name to a given concept?

Complete agreement from me. For what it's worth, "return" can mean "to shift back to a previous topic", so it's not _that_ crazy for when you've switched from a monadic context to a pure context and are now switching back.

Return is all about providing a value *when used transitively*. When used intransitively, it's about moving yourself. There's nothing about the latter sense that implies providing a value. Which is not to say Richard did not overstate the case - "return needn't necessarily (in English) suggest providing a value" would be more correct, but isn't that far from a charitable interpretation of what he'd said. On Wed, Aug 7, 2013 at 7:56 AM, Donn Cave wrote:

quoth Richard A. O'Keefe, ...

...

If you're familiar with *English* rather than, say, the C family of programming languages, "return" isn't _that_ bad, there is certainly nothing about the word that suggests providing a value.

The RFC822 headers of your email suggest that you use a Macintosh computer, so apart from the apparently disputable question of whether you're familiar with English, you have the same online dictionary as mine. Second definition: "give, put, or send (something) back to a place or person", with examples "she returned his kiss", usage from tennis and football, verdicts, etc. Third definition: "yield or make a profit", fourth (re)elect a person or party. "Return" is all about providing a value, in English.

When a term like "return" is used in a computer programming language in a sense that confounds any prior expectation based on English or other programming languages, that's the opposite of "intuitive". It "is what it is", and it's silly to talk about changing it at this point, but that doesn't mean that we have to turn the notion of "intuitive" on its head.

Donn

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

quoth Richard A. O'Keefe

Check the OED. Most of its meaning are about _turning back_, _resuming_, _reverting_. Yielding or making a profit is not at all about "providing a value", but about money going out AND COMING BACK. It's the coming back part that makes it a "return".

Yes. Return means 'go/come back'; used transitively, it means 'go/come back with _'.

"value" occurs twice in OED 'return, v.1", in neither case referring to providing a value.

But of course, the word "value" as we use it is specific to our application, i.e. it's computer jargon, with an English meaning that's more like "thing", "object", "datum". Wouldn't look for "value" to convey this meaning in an OED definition of "return".

In all of the senses, the underlying idea is not provision of a value, but going, turning, or bending back.

[Which is actually what the Haskell return fails to do.] What goes/turns/bends back? When used intransitively, the subject; used transitively, the object, our "value." I'll give you the COBOL example, it's no better the Haskell return. FORTRAN makes a good deal more sense for an English speaker but uses indirect object semantically - RETURN 2 means return to the second alternate return specified by the caller. (I never used that feature, so don't take my word for it, check your manual before using it!) Donn

Richard A. O'Keefe :

Haskell has*trained* my intuition to see 'putStrLn "Hi"' as a pure value; it's not the thing itself that has effects, but its interpretation by an outer engine, just as my magnetic card key has by itself no power to open doors, but the magnetic reader that looks at the card _does_. I am the last here who would quarrel with Richard O'K., but I firmly believe that such reasoning is a Pandora box.

The King, the government, the Pope, etc. have no power, only the interpretation of their decrees by "outer agents" _does_ things. Saying that the Justice of the country X is lousy is a harmful abuse. Our Justice is good, only its interpretation by some incompetent traitors gave rise to all these calamitous events. You see what I mean?... Are we going to switch now to the Mind-Body dilemma? == BTW. Saying that "5" is a pure value means only that the whole of the underlying system treats it as such. The object "5" couldn't care less. It even doesn't know that in some programming language it is equivalent to an action which puts it on the evaluation stack. That's why for me the "purity" (while teaching I try to avoid this word) means simply that whatever you do with the object, it won't fire a "magic" process. As Richard, I do not claim that this is "right", but it surely facilitated my teaching of Haskell. My students have already more than enough of my /philosophie de pacotille/... Jerzy Karczmarczuk

On 7/08/2013, at 9:17 PM, Jerzy Karczmarczuk wrote:

I am the last here who would quarrel with Richard O'K., but I firmly believe that such reasoning is a Pandora box.

The King, the government, the Pope, etc. have no power, only the interpretation of their decrees by "outer agents" _does_ things.

I regard the analogy as flawed because my sovereign [Her Majesty Elizabeth the Second, by the Grace of God Queen of New Zealand and Her Other Realms and Territories, Head of the Commonwealth, Defender of the Faith/Her Majesty Elizabeth the Second, by the Grace of God, Queen of Australia and Her other Realms and Territories, Head of the Commonwealth (I have dual citizenship, so she gets to be my Queen twice) ] is a moral agent, so is the Bishop of Rome, and so are my Prime Ministers John Key and Kevin Rudd. These people are agents in their own right; they and the people who follow their orders are _things of the same kind_. Maybe the analogy isn't that flawed. Julia Gillard found out that when enough people stopped saying "yes" to her, her power disappeared like morning dew. The official teaching of the Roman church is that contraception is not OK, yet the 2013 birth rates for Spain and Portugal were about 1.5. It really does look as though the Pope's power does rest on the consent of the people: if people don't like what he tells them, they don't do it. I leave it to other readers with a misspent youth to supply the name and title of the Science Fiction story in which "FIW" is the political key. Analogies are helpful if they help. Comparing IO 'actions' to plain old data like a magnetic card key and the Haskell environment to the reader helped _me_; if it helps no-one else, forget it.

What about X, Y, Z, ... We have seen this discussion already a long time ago. The terms "unit" and "result" have been proposed. And others. Somebody (I forgot who) advocated even the name "monad" in this context. And this might have continued forever... With all my respect, I see that Haskell reached finally the Noble Domain of Philosophy. I mean, instead of discussing concepts, people begin to discuss names. And since for some, even IO () is a "pure" value, I suspect that the next round will rekindle the discussion on the word "pure"... Jerzy Karczmarczuk

Le 06/08/2013 11:01, J. Stutterheim a écrit :

... So in reply to Jerzy, I do want to encourage the discussion in the "Noble Domain of Philosophy" and I also want to repeat that I am not proposing to change Haskell or Haskell libraries

Jurriën, I taught Haskell for several years. I saw the disgraceful confusion in heads of my students whose previous programming experience was based on Python, and who learned Haskell and Java in parallel. So, I won't claim that names are irrelevant. And "return" in particular. However, my personal "philosophy" is the following: accept the fact that words in one language -- formal or natural -- mean something different than in another one. [[In French the word "file" in computerese is "queue" in English; this is in fact a French word meaning "tail" in English, and I have several dozens of such examples... And so what?...]] It is good to choose consciously some good names while elaborating a standard. But getting back to it after several years, is -- for me -- a waste of time. This, unfortunately, pollutes the true philosophy as well. I believe that at least 80% of the "progress" in the philosophy of religions belongs to the linguistic domain. The anglosaxons corupted the word "semantics", used in a pejorative sense: "discussion about superficialities, the words, not the concepts", while the true semantics is about the true sense. So, sorry for being sarcastic, or even cynical in my previous post, but I sincerely think that oldies are oldies, let them be, and work more on issues that are still evolving. All the best. Jerzy

On 06.08.2013 10:46, Adam Gundry wrote:

On 06/08/13 06:14, J. Stutterheim wrote:

...

Suppose we now have the opportunity to change the name of the `return` function in Monad, what would be a "better" name for it? (for some definition of better)

Rather than proposing a different name, I'm going to challenge the premise of your question. Perhaps it would be better if `return` had no name at all. Consider the following:

return f `ap` s `ap` t

f <$> s <*> t

do { sv <- s ; tv <- t ; return (f sv tv) }

Indeed, I wished the 0-ary case would be more alike to the unary and binary case, cf. return f0 f1 <$> a1 f2 <$> a1 <*> a2 What is needed is a nice syntax for "idiom brackets".

These are all different ways of spelling

f s t

plus the necessary applicative or monadic bureaucracy. But why couldn't we write just the plain application, and let the type system deal with the plumbing of effects?

I would not think this is practically possible. For instance, if f :: a -> b -> c then it could be a binary function or a unary function in the context monad reading from a, thus, application f x is ambiguous or too sensitive, especially with type inference.

I realise that this may be too open a research area for your project...

-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

| Indeed, I wished the 0-ary case would be more alike to the unary and | binary case, cf. | | return f0 | f1 <$> a1 | f2 <$> a1 <*> a2 | | What is needed is a nice syntax for "idiom brackets". Indeed. I'm quite open to adding idiom brackets to GHC, if everyone can agree on their syntax, and someone would like to offer a patch. Something like (| f a1 a2 |) perhaps? Simon

On Thu, Aug 15, 2013 at 5:39 AM, Jason Dagit wrote:

Also, if anyone wants to look at prior art first, Idris supports applicative brackets.

As does she [0]. Erik [0] https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/idiom.html

Dag Odenhall writes:

I particularly like she's (her?) syntax for Alternative. Not sure whether or not Idris has that. Applicative tuples would be nice too, something like (|a,b,c|) translating to liftA3 (,,) a b c. And operators too, liftA2 (+) a b as (| a + b |)?

I patched she and did applicative tuples. Check my recent blog post on it: http://blog.bezirg.net/posts/2013-08-03-enhancement-to-the-strathclyde-haske... She already does lifting of binary operators, AFAIK. Cheers

On Thu, Aug 15, 2013 at 11:08 AM, Erik Hesselink

...

wrote:

On Thu, Aug 15, 2013 at 5:39 AM, Jason Dagit wrote: > Also, if anyone wants to look at prior art first, Idris supports applicative > brackets.

As does she [0].

Erik

[0] https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/ idiom.html

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

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

If we're adding applicative brackets, it would be nice to have something like ⦇⦈ as options via UnicodeSyntax. When playing around with She, I found it much easier to read than the ASCII version, especially when I needed to combine them: (|(|a + b|) + (|c * d|)|) ⦇⦇a + b⦈ + ⦇c * d⦈⦈ Coincidentally, She is the perfect way to experiment with idiom brackets while thinking about a patch like this. I found it very illustrative just to go through old code and see what could really be improved and what couldn't. For me personally, I certainly found *some* code became more readable, but not quite as much as I expected. On Thu, Aug 15, 2013 at 10:44 AM, Anton Nikishaev wrote:

Simon Peyton-Jones writes:

...

| Indeed, I wished the 0-ary case would be more alike to the unary | and binary case, cf. | | return f0 | f1 <$> a1 | f2 <$> a1 <*> a2 | | What is needed is a nice syntax for "idiom brackets".

Indeed. I'm quite open to adding idiom brackets to GHC, if everyone can agree on their syntax, and someone would like to offer a patch.

Something like (| f a1 a2 |) perhaps?

I can make a patch after people agree on everything.

There's also http://hackage.haskell.org/package/applicative-quoters with its template haskell nastiness

h> :m +Control.Applicative.QQ.Idiom h> :set -XQuasiQuotes h> [i| (,) "THX" "BYE" |]

[('T','B'),('T','Y'),('T','E'),('H','B'),('H','Y'),('H','E'),('X','B'),('X','Y'),('X','E')]

-- lelf

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