Functions for builtin operators (?)
Colin Paul Adams
colin at colina.demon.co.uk
Sun May 10 14:05:09 EDT 2009
>>>>> "Simon" == Simon Peyton-Jones <simonpj at microsoft.com> writes:
Simon> sorry, got diverted by paper writing.
Well, I've got diverted by the dragonfly season starting, so i don't
suppose I shall look at this again until October.
Simon> GHC desugars Hsakell into Core, and it's Core that you are consuming in the ESC
Simon> stuff. However, Core for an *overloaded* function contains
Simon> dictionary applications and abstractions. Furthermore,
Simon> overloaded operators turn into selectors, which pick out a
Simon> particular field from a dictionary. See any description of
Simon> how to compile type classes for examples of this.
Simon> So here you've got something like (>) d x y where (>) is
Simon> defined like this (>) (MkOrd _ _ gr _) = gr That is, (>)
Simon> picks out the gr field from the dictionary. So it's all
Simon> very higher-order in reality. And that is what is giving
Simon> trouble to the ESC stuff. After all, what do we know about
Simon> *all* implementations of (>) at *all* types? Not much!
Simon> Dana and I did not explore much how to give a good
Simon> treatment to overloaded functions. I would not expect it
Simon> to "just work".
Simon> I hope this helps a bit
I feared it wasn't going to be easy.
Maybe I'll think about it in October.
More information about the Glasgow-haskell-users