<div>Actually, it looks like a dirty technological impedence.</div><div><br></div><div>Haskell makes functions first class values, but still data values are easier to handle than functions, since their type can implement the Eq typeclass, thanks to constructor matches.</div>
<div><br></div><div><br></div><div>While I got your point, I'm still wondering about functions as constructor of other functions thus it would be possible to match to the function name like we do for type constructors.</div>
<div>I can't have an insight about why this is wrong. Why can't we treat functions as constructors?</div><div><br></div><div><br></div><div>The point, I guess, is that this would assign a kind of "identity" to morphisms that belong to a category. I see how this might be wrong: functions can be equivalent exactly like integers, but they are just harder to implement.</div>
<div><br></div><div>Thus we are back to the dirty technical problem of evaluating function equivalence.</div><div><br></div><div><br></div><div>Giacomo</div><br><div class="gmail_quote">On Mon, Dec 12, 2011 at 2:27 AM, Felipe Almeida Lessa <span dir="ltr"><<a href="mailto:felipe.lessa@gmail.com">felipe.lessa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Dec 11, 2011 at 8:09 PM, Graham Gill <<a href="mailto:math.simplex@gmail.com">math.simplex@gmail.com</a>> wrote:<br>
> Excellent, thanks Daniel and Felipe.<br>
><br>
> We don't even need to invoke infinite or undecidable problems, since it's<br>
> easy to construct equal functions for which determining equality would be<br>
> prohibitively expensive. If then you can only check equality for some<br>
> functions, because you want compilation to finish, say, within the<br>
> programmer's lifetime, you lose referential transparency.<br>
<br>
</div>Note that the time isn't spent on compilation time, but on run time!<br>
Which is actually worse ;-).<br>
<br>
Also note that it is possible to imagine something like<br>
<br>
obviouslyEqual :: a -> a -> Bool<br>
<br>
where 'obviouslyEqual x y' is 'True' when it's easy to see that they<br>
are equal or 'False' if you can't decide. Actually, with GHC you may<br>
say<br>
<br>
{-# LANGUAGE MagicHash #-}<br>
<br>
import GHC.Exts<br>
<br>
obviouslyEqual :: a -> a -> Bool<br>
obviouslyEqual a b =<br>
case I# (reallyUnsafePtrEquality# a b) of<br>
0 -> False<br>
_ -> True<br>
<br>
However, this functions is *not* referentially transparent (exercise:<br>
show an example of how obviouslyEqual breaks referential<br>
transparency). reallyUnsafePtrEquality# is really unsafe for a reason<br>
=).<br>
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Felipe.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
</div></div></blockquote></div><br>