Functions for builtin operators (?)

Colin Paul Adams

8 Apr 2009 8 Apr '09

5:32 a.m.

Where is a function with a name like the following defined in the ghc source code? .Classes.>_ ( tpl_B6 ) I've tried searching for such names - all I can find is a comment referring to tpl_B2. -- Colin Adams Preston Lancashire

Show replies by date

Simon Peyton-Jones

8 Apr 8 Apr

5:48 a.m.

Nowhere. It's a name generated by GHC itself during compilation. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Colin Paul Adams | Sent: 08 April 2009 10:33 | To: glasgow-haskell-users@haskell.org | Subject: Functions for builtin operators (?) | | Where is a function with a name like the following defined in the ghc source | code? | | .Classes.>_ ( tpl_B6 ) | | I've tried searching for such names - all I can find is a comment | referring to tpl_B2. | -- | Colin Adams | Preston Lancashire | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Colin Paul Adams

6:03 a.m.

...

...
...
...
...
"Simon" == Simon Peyton-Jones writes:

Simon> Nowhere. It's a name generated by GHC itself during Simon> compilation. OK. Is there some way to recognise what the function is? The problem is with ESC/Haskell. I have managed to get the code integrated into the 6.11 tree, and it works up to a point. It produces output like: Len.hs:4:0: Len.pos does not satisfy its contract! Counter example: Len.pos with argument(s) x (Inside _GHC.Classes.>_ ( tpl_B6 )) x ((GHC.Types.I# 0)) which is basically saying that it can't trust _GHC.Classes.>_ ( tpl_B6 ) to do anything in particular, as it doesn't know anything about it. So it would be good to add code that recognises these functions. At best, to know the semantics of each one. Colin> | Where is a function with a name like the following Colin> defined in the ghc source | code? Colin> | Colin> | .Classes.>_ ( tpl_B6 ) -- Colin Adams Preston Lancashire

Simon Peyton-Jones

10 May 10 May

1:52 p.m.

sorry, got diverted by paper writing. GHC desugars Hsakell into Core, and it's Core that you are consuming in the ESC stuff. However, Core for an *overloaded* function contains dictionary applications and abstractions. Furthermore, overloaded operators turn into selectors, which pick out a particular field from a dictionary. See any description of how to compile type classes for examples of this. So here you've got something like (>) d x y where (>) is defined like this (>) (MkOrd _ _ gr _) = gr That is, (>) picks out the gr field from the dictionary. So it's all very higher-order in reality. And that is what is giving trouble to the ESC stuff. After all, what do we know about *all* implementations of (>) at *all* types? Not much! Dana and I did not explore much how to give a good treatment to overloaded functions. I would not expect it to "just work". I hope this helps a bit Simon | -----Original Message----- | From: Colin Paul Adams [mailto:colin@colina.demon.co.uk] | Sent: 08 April 2009 11:04 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Functions for builtin operators (?) | | >>>>> "Simon" == Simon Peyton-Jones writes: | | Simon> Nowhere. It's a name generated by GHC itself during | Simon> compilation. | | OK. | Is there some way to recognise what the function is? | | The problem is with ESC/Haskell. I have managed to get the code | integrated into the 6.11 tree, and it works up to a point. | | It produces output like: | | Len.hs:4:0: | Len.pos does not satisfy its contract! | Counter example: | Len.pos with argument(s) x | (Inside _GHC.Classes.>_ ( tpl_B6 )) x ((GHC.Types.I# 0)) | | which is basically saying that it can't trust _GHC.Classes.>_ ( tpl_B6 | ) to do anything in particular, as it doesn't know anything about it. | | So it would be good to add code that recognises these functions. At | best, to know the semantics of each one. | | Colin> | Where is a function with a name like the following | Colin> defined in the ghc source | code? | Colin> | | Colin> | .Classes.>_ ( tpl_B6 ) | | | | -- | Colin Adams | Preston Lancashire

Colin Paul Adams

2:05 p.m.

...

...
...
...
...
"Simon" == Simon Peyton-Jones 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 Thanks. I feared it wasn't going to be easy. Maybe I'll think about it in October. -- Colin Adams Preston Lancashire

5854

Age (days ago)

5886

Last active (days ago)

List overview

Download

4 comments

2 participants

participants (2)

Colin Paul Adams
Simon Peyton-Jones