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

Richard A. O'Keefe

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.


_______________________________________________
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 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.


_______________________________________________
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

Timon Gehr
In reply to this post by Jerzy Karczmarczuk
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.)


_______________________________________________
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 Donn Cave-4

On 8/08/2013, at 2:56 AM, Donn Cave wrote:
> 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.

My department has an electronic subscription to the OED.

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

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".

"value" occurs twice in OED 'return, v.1", in neither case
referring to providing a value.
OED "re-turn, v.2" has "value" once, again not referring to
providing a value (in fact, to detecting possible theft).
OED "return, n" has "the fact or an instance of bringing value
in exchange for effort or investment", where the salient part
is "IN EXCHANGE FOR":  effort going out, value COMING BACK.
There are two other similar senses, out of I don't know how
many senses (because I lost count after 80).

A "return" can be "a reply, answer or retort" (as in the Fool's
"Marry, it was a sharp retort" in one of the Discworld novels,
when an alchemist's vessel exploded), "a summary of a [cricket]
play's bowling or batting performance", "a response to a demand",
"a wing or side of a building", or "a side street", among many
other things.

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

> 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".

OK, so when in the past someone met "RETURN" in their second programming
language, what had their experience taught them to expect?

ISO/IEC 1989:20xx CD 1.2 (E)

    14.9.32 RETURN statement

    The RETURN statement obtains either sorted records from the final
    phase of a sort operation or merged records during a merge operation.

    14.9.32.1 General format

    RETURN file-name-1 RECORD [ INTO identifier-1 ]
       AT END imperative-statement-1
    [ NOT AT END imperative-statement-2 ]
  [ END-RETURN ]

This is a somewhat more elaborate form of a statement which has been
present in COBOL since at least 1974 and probably longer.  The latest
estimate I've seen is that four thousand million lines of new COBOL
are added every year.

Operationally, the COBOL RETURN statement is more like a READ than
anything else.




_______________________________________________
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
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

_______________________________________________
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
In reply to this post by Jerzy Karczmarczuk
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

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

Identity of indiscernibles (Was: Alternative name for return)

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

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: Identity of indiscernibles (Was: Alternative name for return)

Tom Ellis
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

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

Re: Identity of indiscernibles (Was: Alternative name for return)

Jake McArthur

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"? Maybe you could argue that they aren't operationally equivalent, but can you guarantee that such reordering are *never* operationally equivalent? How about an action that take an input from stdin and then outputs the result of some computation based on it? How do you compare two such actions? I disagree with Jerzy on the purity of IO, but I don't think this line of argument is bound to be very fruitful.

Jerzy, taking a similar example to that last one, would you say functions are impure just because I can't write a general (==) for them? I don't see what bountiful numbers of operations has to do with purity.

- Jake

On Aug 8, 2013 7:21 AM, "Tom Ellis" <[hidden email]> wrote:
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

_______________________________________________
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: Identity of indiscernibles (Was: Alternative name for return)

Tom Ellis
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

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

Re: Identity of indiscernibles

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

Re: Identity of indiscernibles

Tom Ellis
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

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

Re: Identity of indiscernibles

Oliver Charles-3
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] :)



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

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Identity of indiscernibles

Daniel Trstenjak-2
In reply to this post by Tom Ellis

Hi Tom,

> 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?


Greetings,
Daniel

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

Re: Identity of indiscernibles

Tom Ellis
In reply to this post by Oliver Charles-3
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.html

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

Re: Identity of indiscernibles

Tom Ellis
In reply to this post by Daniel Trstenjak-2
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

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

Re: Identity of indiscernibles

Tom Ellis
On Thu, Aug 08, 2013 at 05:44:11PM +0100, Tom Ellis wrote:

> 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)

I suppose that should actually be 'csin :: CDouble -> IO CDouble', but
hopefully the general method is clear.

Tom


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

Re: Identity of indiscernibles

Kim-Ee Yeoh
Administrator
In reply to this post by Tom Ellis

On Thu, Aug 8, 2013 at 11:05 PM, Tom Ellis <[hidden email]> 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?

-- Kim-Ee

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

Re: Identity of indiscernibles

Tom Ellis
On Fri, Aug 09, 2013 at 12:38:45AM +0700, Kim-Ee Yeoh wrote:

> On Thu, Aug 8, 2013 at 11:05 PM, Tom Ellis <[hidden email]> 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].

I'm not proposing it.  I'm just pointing out it could be done, as a
challenge to Jerzy's assertion that "In fact, you can do almost nothing with
[values of type IO ()]".

However, I may have misunderstood Jerzy's point anyway.

Tom

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

Re: Identity of indiscernibles

Jake McArthur
In reply to this post by Jerzy Karczmarczuk

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


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