[Haskell-beginners] Pattern matching over functions

Giacomo Tesio giacomo at tesio.it
Mon Dec 12 16:47:37 CET 2011


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 at gmail.com> wrote:

> On Sun, Dec 11, 2011 at 8:09 PM, Graham Gill <math.simplex at 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.
>
> Note that the time isn't spent on compilation time, but on run time!
> 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.
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20111212/223d11fb/attachment.htm>


More information about the Beginners mailing list