Actually, it looks like a dirty technological impedence.
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.
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.
I can't have an insight about why this is wrong. Why can't we treat functions as constructors?
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.
Thus we are back to the dirty technical problem of evaluating function equivalence.
Giacomo
On Mon, Dec 12, 2011 at 2:27 AM, Felipe Almeida Lessa
<felipe.lessa@gmail.com> wrote:
On Sun, Dec 11, 2011 at 8:09 PM, Graham Gill <
math.simplex@gmail.com> wrote:
> Excellent, thanks Daniel and Felipe.
>
> We don't even need to invoke infinite or undecidable problems, since it's
> easy to construct equal functions for which determining equality would be
> prohibitively expensive. If then you can only check equality for some
> functions, because you want compilation to finish, say, within the
> programmer's lifetime, you lose referential transparency.
Which is actually worse ;-).
Also note that it is possible to imagine something like
obviouslyEqual :: a -> a -> Bool
where 'obviouslyEqual x y' is 'True' when it's easy to see that they
are equal or 'False' if you can't decide. Actually, with GHC you may
say
{-# LANGUAGE MagicHash #-}
import GHC.Exts
obviouslyEqual :: a -> a -> Bool
obviouslyEqual a b =
case I# (reallyUnsafePtrEquality# a b) of
0 -> False
_ -> True
However, this functions is *not* referentially transparent (exercise:
show an example of how obviouslyEqual breaks referential
transparency). reallyUnsafePtrEquality# is really unsafe for a reason
=).
Cheers,
--
Felipe.