[Haskell-cafe] Serialization of (a -> b) and IO a

[John Lato]

>
> From: Sjoerd Visscher <sjoerd at w3future.com>
>
> On Nov 11, 2010, at 3:36 PM, Dan Doel wrote:
>
> > On Thursday 11 November 2010 6:22:06 am Sjoerd Visscher wrote:
> >
> >> The reasoning above is used regularly to shoot down some really useful
> >> functionality. So what would go wrong if we chose to take the practical
> >> path, and leave aside the theoretical issues?
> >
> > You would lose many uses of equational reasoning in your programs. Have
> you
> > every substituted 'x * 2' for the expression 'x + x' in one of your
> programs,
> > or vice versa? You can no longer do that, because someone may be
> serializing
> > the function you're writing, checking how it's implemented, and relying
> it.
>
>
> Yes, but it would not break any existing code. It would only break code
> that knowingly did the wrong thing.
>
> > We already have a weak case of this, since (\x -> undefined x) can be
> > distinguished from undefined using seq, but that can be hand-waved away
> by not
> > worrying about bottoms so much. That isn't going to work for serialize.
>
> Why not?
>

I don't know to what extent it would apply in this hypothetical situation,
but ghc (and probably other compilers) rely upon Haskell's semantics in
performing various code transformations.  If you break the semantics some
transformations become invalid, resulting in incorrect code.

I've experienced this with code that violated ref. transparency.  The
program behavior changed depending on the compiler's optimization settings.
 I'm not keen to go back to that.

I think the only way this would work would be if you consider functions to
be equal only to themselves, i.e. "x+x" and "2*x" are not equal.  That's not
a trade-off I would be willing to make.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20101111/1e2ae561/attachment.html