Alternative name for return

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

Re: Alternative name for return

Jake McArthur

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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe


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


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

Re: Alternative name for return

Brandon Allbery
In reply to this post by J. Stutterheim
On Tue, Aug 6, 2013 at 4:03 AM, J. Stutterheim <[hidden email]> wrote:
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?

I actually have the opposite problem: what's impure about lifting 5 into Maybe or []? `pure` feels IO-targeted.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

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

Re: Alternative name for return

Jerzy Karczmarczuk
In reply to this post by Jake McArthur
Le 06/08/2013 14:47, Jake McArthur a écrit :
... 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

As I said,  --
Now Is The Time  --
[[choose your reference of this Original Expression; perhaps the albums of Alanis Morissette or that of Jeff Lorber...]]

... to discuss the Purity. Go ahead and good luck.

Unfortunately I belong to a Cretacean generation, for whom the Referential Transparency means something, so I don't believe you, Jake.  I am not saying that you are wrong. I say that calling an action a pure value is almost meaningless.

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 (>>=).

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. You know all this as well as I do, perhaps better. That's why the "purity" here is dubious (although, unless I am mistaken, all functional constructs are considered "pure" by Wadler...).

3. Brandon Albery is (in my eyes) right:
what's impure about lifting 5 into Maybe or []? `pure` feels IO-targeted.

A list, such as (return 5) in the List/Nondet Monad may be treated as a normal data item. But a IO action, or a IoRef mutable reference -- not really, they are Magic. If you claim that Magic is Pure, I abandon the ring. For me the Magical entities (i.e., the entities which are controlled by some layers UNDER the one YOU control) are impure, since there is no operational definition of purity for them. "No side effects"? Sure, if you don't do anything with it. Even the most horrible Devil is pure. Unless you call it...


Jerzy Karczmarczuk



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

Re: Alternative name for return

Tom Ellis
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 ().

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

Re: Alternative name for return

Albert Y. C. Lai
In reply to this post by J. Stutterheim
On 13-08-06 01:14 AM, J. Stutterheim wrote:
> 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`.

I suggest "simply".

Having said that, I like all the other names too.

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

Re: Alternative name for return

Dan Burton
In reply to this post by Tom Ellis

Bikeshedding at its finest. I think if we are very lucky, then a long time from now we will be able to deprecate "return" in favor of "Control.Applicative.pure"

As for making it "invisible", that's what idiom brackets and monad comprehensions are for. But for those creating an *instance* of Monad, well, we obviously need to be able to refer to which operation we are implementing.

I like the idea of using "lift", because this is the word used for MonadTrans, which is the same operation, but in the category of Haskell Monads instead of the category of Hask. However, it is convenient to have both in scope unqualified, so maybe lift would not be the best choice.

-- Dan Burton

On Aug 6, 2013 7:38 AM, "Tom Ellis" <[hidden email]> wrote:
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 ().

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

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

Re: Alternative name for return

Richard A. O'Keefe
In reply to this post by J. Stutterheim

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Alternative name for return

damodar kulkarni
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: Alternative name for return

Brandon Allbery
In reply to this post by Richard A. O'Keefe
On Tue, Aug 6, 2013 at 9:10 PM, Richard A. O'Keefe <[hidden email]> 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).

Them and a small and slowly shrinking group of folks who find it intuitive because obviously only the first 6 characters of an imported function are significant :)

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

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

Re: Alternative name for return

Richard A. O'Keefe
In reply to this post by damodar kulkarni

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Alternative name for return

Jerzy Karczmarczuk
In reply to this post by Richard A. O'Keefe
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


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

Re: Alternative name for return

Alberto G. Corona
In reply to this post by Richard A. O'Keefe
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 <[hidden email]>

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alberto.

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

Re: Alternative name for return

Alberto G. Corona
In reply to this post by Jerzy Karczmarczuk
Fine reasoning.
 
Pure means incorruptible. It means that a pure result can be reused again and again -like the gold or silver- while an impure result must be re-created whenever it must be used. The metaphor is natural and I guess that the use of pure (rather than referential transparent) is informal, but as unavoidable as useful.  By the way, there are deeper considerations here: To deal with pure values, like incorruptible stuff, like gold implies lower information costs and that´s one of the reasons why they are valuable.
 
In this sense, we can give a positive meaning to unsafePerformIO and change its name to  "purify" or  even "pasteurize" or "lyophilize" ;)
 
 
 
 


2013/8/7 Jerzy Karczmarczuk <[hidden email]>
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


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




--
Alberto.

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

Re: Alternative name for return

damodar kulkarni
In reply to this post by Richard A. O'Keefe

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

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?

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?
It will help others to share *at least some amount of* of intuition (analogy) the originator had had.

Are such thoughts documented in this case?

Thanks and regards,
-Damodar Kulkarni


On Wed, Aug 7, 2013 at 11:37 AM, Richard A. O'Keefe <[hidden email]> wrote:

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Alternative name for return

Donn Cave-4
In reply to this post by Richard A. O'Keefe
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Alternative name for return

David Thomas
In reply to this post by Jerzy Karczmarczuk

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.

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

Re: Alternative name for return

David Thomas
In reply to this post by Donn Cave-4
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: Alternative name for return

Joe Quinn
In reply to this post by David Thomas
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!

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

Re: Alternative name for return

Bardur Arantsson-2
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.




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

Re: Alternative name for return

Jerzy Karczmarczuk
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.

You make the distinction between "evaluate", and  "execute" or  "run", etc. This is not functional. 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...).

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. It is a kind of counterfeit notion, inherited from "pure functions" to something which belongs to two different worlds.

Jerzy Karczmarczuk

PS. I believe that some impure remarks about the familiarity of X or Y with English do not belong to this forum.



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