[Haskell-cafe] Identity of indiscernibles (Was: Alternative name for return)
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Identity of indiscernibles (Was: Alternative name for return)
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Identity of indiscernibles (Was: Alternative name for return)
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 tom-lists-haskell-cafe-2...@jaguarpaw.co.uk 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 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
Re: [Haskell-cafe] Identity of indiscernibles (Was: Alternative name for return)
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
