Re: Determine instance method from class method callsite

[Robin Palotai]

About "Var" - that is just a Name with additional info, but happens in the
typechecked tree (according to API docs).

2017-10-05 18:00 GMT+02:00 Simon Peyton Jones :

> well the HsWrapper might have something much more complicated than a
> DFunId.  It might need to construct the dictionary for Eq [a] from the DFun
> for Eq [a] and a dictionary for Eq a.
>
>
>
> it would be easy to resolve the Var of the instance method.
>
> I don’t know what “the var of the instance method” is.
>
>
>
> I feel I’m missing the point.  maybe others can help?
>
>
>
> Simon
>
>
>
> *From:* Robin Palotai [mailto:palotai.ro...@gmail.com]
> *Sent:* 05 October 2017 11:17
> *To:* Simon Peyton Jones 
> *Cc:* GHC developers ; haskell <
> haskell-c...@haskell.org>
> *Subject:* Re: Determine instance method from class method callsite
>
>
>
> Hello Simon - I outlined the approach in https://github.com/google/
> haskell-indexer/issues/73
> 
> .
> TLDR is
> 1) at callsite, indeed the HsWrapper needs to be analysed to get the
> instance DFunId
>
> 2) at instance declaration site, we need to again take note of the DFunId.
>
> It is slightly more complicated than I expected the API. I would have
> expected that from having the Var of a class method, and the  of
> the instance (here DFunId), it would be easy to resolve the Var of the
> instance method.
>
> But it seems there's no direct way, one has to build a lookup table from
> the instance methods' (DFunId + plain stringy method name), and look that
> up from the callsite.
>
> Or I might have missed a way to deconstruct / query a DFunId for the
> method Vars.
>
> I'll put augmenting the commentary on my mental TODO list :)
>
>
>
> 2017-10-05 11:58 GMT+02:00 Simon Peyton Jones :
>
> Did you get a reply?
>
>
>
> I’m not 100% certain of your question, but consider the
>
>
>
> bar = show 
>
> for some expression e.   In the input to the type type checker the syntax
> tree for the RHS will be something like
>
> HsApp (HsVar “show”) 
>
>
>
> (The “show” isn’t really a string, it’s the Name for the class method.)
>
>
>
> After typechecking the syntax tree is augmented (or “elaborated”) with
> type and dictionary application.  So in concrete form it might look like
>
> bar = show @Foo dShowFoo 
>
>
>
> Because show :: forall a. Show a => a -> String, so show is apply to the
> type of its argument, and then to the dictionary.
>
>
>
> In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The
> elaborated syntax tree look like
>
>
>
> HsApp (HsWrap  (HsVar “show”))
>
>   
>
>
>
> The  part expresses the type and dictionary application. In this
> case it’ll look like
>
> WpEvApp dShowFoo (WpTyApp Foo WpHole)
>
>
>
> See the notes with `HsWrapper` in TcEvidence.
>
>
>
> Does that help?
>
>
>
> It would be great to augment the https://ghc.haskell.org/trac/
> ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it
> already).  If you augment I can review.  Email is quickly lost.
>
>
>
> Simon
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Robin
> Palotai
> *Sent:* 19 September 2017 06:39
> *To:* GHC developers ; haskell <
> haskell-c...@haskell.org>
> *Subject:* Determine instance method from class method callsite
>
>
>
> Sorry, I messed up subject and mailing list. Copying to both list now
> after the mistake (wanted only ghc-devs for specificity).
>
>
>
> Thanks!
>
>
>
> 2017-09-19 7:36 GMT+02:00 Robin Palotai :
>
> Hello GHC devs,
>
>
>
> Before inventing the wheel, want to check if there is a GHC API way to
> look up the (fully) resolved instance method from a class method.
>
>
>
> For example, given a code
>
>
>
> data Foo Int deriving Show
>
>
>
> bar = show (Foo 3)
>
>
>
> when inspecting the Typechecked AST for bar's show call, I would like to
> get to the Name / Id of 'show' of the 'Show' typeclass.
>
>
>
> I believe I could use splitHsSigmaTy on the HsType of the function call to
> get the context, and then evaluate the HsWrapper somehow to find out what
> instance dictionary is applied to the class restriction in the context, and
> then look up the instance method from the dictionary..
>
>
>
> Two questions:
>
>
>
> 1) Is there maybe functionality for this?
>
>
>
> 2) If not, is there any guarantee about the constraint order in the
> context, at the method call? So I could more easily determine which
> constraint's application to look for..
>
>
>
> Any hints welcome && Thank you!
>
> Robin
>
>
>
>
>

Re: In C--: should CmmCall and CmmProc agree on their live registers?

[Moritz Angermann]

Hi Simon,

no, I did not until now. Thank you! As such it is acceptable that the CmmCalls
set of live registers is a superset of the CmmProcs live registers that is 
called.

Say we shrink the set of live registers of the CmmProc, as we determine that 
some of the
arguments passed in registers are not used in the graph at all.  Would we want 
to
propagate this information to the CmmCall if possible?

Cheers,
 Moritz


> On Oct 5, 2017, at 5:59 PM, Simon Peyton Jones  wrote:
> 
> Did you ever get a reply to this?
> 
> In the output of the codegen, CmmProcs should have no live registers apart 
> from those used to pass args, and the standard ones.
> 
> Simon
> 
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz
> |  Angermann
> |  Sent: 22 September 2017 07:33
> |  To: GHC developers 
> |  Subject: In C--: should CmmCall and CmmProc agree on their live registers?
> |  
> |  Hi,
> |  
> |  apologies for writing so many emails recently. This is a minor spinoff from
> |  the "The Curious Case of T6084" email.
> |  
> |  While digging into it, I keep asking myself if CmmProc’s live registers
> |  should match those of the CmmCall that is calling it?
> |  
> |  Is there any invariant we try to enforce or would want to enforce?
> |  
> |  - Can the CmmProcs live registers be a strict superset of
> |the corresponding CmmCalls?
> |  
> |From the source comments in `compiler/cmm/Cmm.hs`:
> |> Registers live on entry. Note that the set of live
> |> registers will be correct in generated C-- code, but
> |> not in hand-written C-- code. However,
> |> splitAtProcPoints calculates correct liveness
> |> information for CmmProcs.
> |  
> |I would assume that this is an invalid case?
> |  
> |  - Can the CmmProcs live registers be a strict subset of
> |the corresponding CmmCalls?
> |  
> |This case however seems to be valid case.  However, this
> |makes me wonder if we can, and should(?) propagate the
> |live register info from the CmmProc to the CmmCall so
> |that they match up, and the registers are not kept live
> |at the origin of the CmmCall if they aren’t needed?  And
> |as such potentially compute anything to put into the
> |registers the CmmCall considers live, but the CmmProc
> |would ignore anyway?
> |  
> |  Cheers,
> |   Moritz
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
> |  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  
> devs=02%7C01%7Csimonpj%40microsoft.com%7C6009bb0f47a447a4217708d50183ce
> |  
> fa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416587981602708=vII
> |  rlKVJa6E%2FBvVz5Sod1c544nw6gsGp54Mlhr7bQ8g%3D=0

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Deprecating STM invariant mechanism

[Ben Gamari]

tl;dr. Do you use Control.Monad.STM.always? If so say so on
   this [1] proposal otherwise the interface may be removed.


Hello everyone,

GHC's STM subsystem has long had the ability to run user-specified
invariant checks when committing transactions, embodied by the
Control.Monad.STM.always and alwaysSucceeds functions.

However, if Hackage is any indication this feature has seen very little
use of the past ten years. In fact, it has very likely been quite broken
(#14310) for this entire duration. 

Consequently, I suggest that we begin deprecating the mechanism. See
the deprecation Proposal [1] for full details. Please leave a comment if
you object.

Cheers,

- Ben


[1] https://github.com/ghc-proposals/ghc-proposals/pull/77


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Determine instance method from class method callsite

[Simon Peyton Jones via ghc-devs]

well the HsWrapper might have something much more complicated than a DFunId.  
It might need to construct the dictionary for Eq [a] from the DFun for Eq [a] 
and a dictionary for Eq a.

it would be easy to resolve the Var of the instance method.
I don't know what "the var of the instance method" is.

I feel I'm missing the point.  maybe others can help?

Simon

From: Robin Palotai [mailto:palotai.ro...@gmail.com]
Sent: 05 October 2017 11:17
To: Simon Peyton Jones 
Cc: GHC developers ; haskell 
Subject: Re: Determine instance method from class method callsite

Hello Simon - I outlined the approach in 
https://github.com/google/haskell-indexer/issues/73.
TLDR is
1) at callsite, indeed the HsWrapper needs to be analysed to get the instance 
DFunId
2) at instance declaration site, we need to again take note of the DFunId.
It is slightly more complicated than I expected the API. I would have expected 
that from having the Var of a class method, and the  of the instance 
(here DFunId), it would be easy to resolve the Var of the instance method.
But it seems there's no direct way, one has to build a lookup table from the 
instance methods' (DFunId + plain stringy method name), and look that up from 
the callsite.
Or I might have missed a way to deconstruct / query a DFunId for the method 
Vars.
I'll put augmenting the commentary on my mental TODO list :)

2017-10-05 11:58 GMT+02:00 Simon Peyton Jones 
>:
Did you get a reply?

I'm not 100% certain of your question, but consider the

bar = show 
for some expression e.   In the input to the type type checker the syntax tree 
for the RHS will be something like
HsApp (HsVar "show") 

(The "show" isn't really a string, it's the Name for the class method.)

After typechecking the syntax tree is augmented (or "elaborated") with type and 
dictionary application.  So in concrete form it might look like
bar = show @Foo dShowFoo 

Because show :: forall a. Show a => a -> String, so show is apply to the type 
of its argument, and then to the dictionary.

In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The 
elaborated syntax tree look like

HsApp (HsWrap  (HsVar "show"))
  

The  part expresses the type and dictionary application. In this case 
it'll look like
WpEvApp dShowFoo (WpTyApp Foo WpHole)

See the notes with `HsWrapper` in TcEvidence.

Does that help?

It would be great to augment the 
https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info 
(insofar as it doesn't have it already).  If you augment I can review.  Email 
is quickly lost.

Simon
From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Robin Palotai
Sent: 19 September 2017 06:39
To: GHC developers >; haskell 
>
Subject: Determine instance method from class method callsite

Sorry, I messed up subject and mailing list. Copying to both list now after the 
mistake (wanted only ghc-devs for specificity).

Thanks!

2017-09-19 7:36 GMT+02:00 Robin Palotai 
>:
Hello GHC devs,

Before inventing the wheel, want to check if there is a GHC API way to look up 
the (fully) resolved instance method from a class method.

For example, given a code

data Foo Int deriving Show

bar = show (Foo 3)

when inspecting the Typechecked AST for bar's show call, I would like to get to 
the Name / Id of 'show' of the 'Show' typeclass.

I believe I could use splitHsSigmaTy on the HsType of the function call to get 
the context, and then evaluate the HsWrapper somehow to find out what instance 
dictionary is applied to the class restriction in the context, and then look up 
the instance method from the dictionary..

Two questions:

1) Is there maybe functionality for this?

2) If not, is there any guarantee about the constraint order in the context, at 
the method call? So I could more easily determine which constraint's 
application to look for..

Any hints welcome && Thank you!
Robin


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Determine instance method from class method callsite

[Robin Palotai]

Hello Simon - I outlined the approach in
https://github.com/google/haskell-indexer/issues/73.
TLDR is
1) at callsite, indeed the HsWrapper needs to be analysed to get the
instance DFunId
2) at instance declaration site, we need to again take note of the DFunId.

It is slightly more complicated than I expected the API. I would have
expected that from having the Var of a class method, and the  of
the instance (here DFunId), it would be easy to resolve the Var of the
instance method.

But it seems there's no direct way, one has to build a lookup table from
the instance methods' (DFunId + plain stringy method name), and look that
up from the callsite.

Or I might have missed a way to deconstruct / query a DFunId for the method
Vars.

I'll put augmenting the commentary on my mental TODO list :)

2017-10-05 11:58 GMT+02:00 Simon Peyton Jones :

> Did you get a reply?
>
>
>
> I’m not 100% certain of your question, but consider the
>
>
>
> bar = show 
>
> for some expression e.   In the input to the type type checker the syntax
> tree for the RHS will be something like
>
> HsApp (HsVar “show”) 
>
>
>
> (The “show” isn’t really a string, it’s the Name for the class method.)
>
>
>
> After typechecking the syntax tree is augmented (or “elaborated”) with
> type and dictionary application.  So in concrete form it might look like
>
> bar = show @Foo dShowFoo 
>
>
>
> Because show :: forall a. Show a => a -> String, so show is apply to the
> type of its argument, and then to the dictionary.
>
>
>
> In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The
> elaborated syntax tree look like
>
>
>
> HsApp (HsWrap  (HsVar “show”))
>
>   
>
>
>
> The  part expresses the type and dictionary application. In this
> case it’ll look like
>
> WpEvApp dShowFoo (WpTyApp Foo WpHole)
>
>
>
> See the notes with `HsWrapper` in TcEvidence.
>
>
>
> Does that help?
>
>
>
> It would be great to augment the https://ghc.haskell.org/trac/
> ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it
> already).  If you augment I can review.  Email is quickly lost.
>
>
>
> Simon
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Robin
> Palotai
> *Sent:* 19 September 2017 06:39
> *To:* GHC developers ; haskell <
> haskell-c...@haskell.org>
> *Subject:* Determine instance method from class method callsite
>
>
>
> Sorry, I messed up subject and mailing list. Copying to both list now
> after the mistake (wanted only ghc-devs for specificity).
>
>
>
> Thanks!
>
>
>
> 2017-09-19 7:36 GMT+02:00 Robin Palotai :
>
> Hello GHC devs,
>
>
>
> Before inventing the wheel, want to check if there is a GHC API way to
> look up the (fully) resolved instance method from a class method.
>
>
>
> For example, given a code
>
>
>
> data Foo Int deriving Show
>
>
>
> bar = show (Foo 3)
>
>
>
> when inspecting the Typechecked AST for bar's show call, I would like to
> get to the Name / Id of 'show' of the 'Show' typeclass.
>
>
>
> I believe I could use splitHsSigmaTy on the HsType of the function call to
> get the context, and then evaluate the HsWrapper somehow to find out what
> instance dictionary is applied to the class restriction in the context, and
> then look up the instance method from the dictionary..
>
>
>
> Two questions:
>
>
>
> 1) Is there maybe functionality for this?
>
>
>
> 2) If not, is there any guarantee about the constraint order in the
> context, at the method call? So I could more easily determine which
> constraint's application to look for..
>
>
>
> Any hints welcome && Thank you!
>
> Robin
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: In C--: should CmmCall and CmmProc agree on their live registers?

[Simon Peyton Jones via ghc-devs]

Did you ever get a reply to this?

In the output of the codegen, CmmProcs should have no live registers apart from 
those used to pass args, and the standard ones.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz
|  Angermann
|  Sent: 22 September 2017 07:33
|  To: GHC developers 
|  Subject: In C--: should CmmCall and CmmProc agree on their live registers?
|  
|  Hi,
|  
|  apologies for writing so many emails recently. This is a minor spinoff from
|  the "The Curious Case of T6084" email.
|  
|  While digging into it, I keep asking myself if CmmProc’s live registers
|  should match those of the CmmCall that is calling it?
|  
|  Is there any invariant we try to enforce or would want to enforce?
|  
|  - Can the CmmProcs live registers be a strict superset of
|the corresponding CmmCalls?
|  
|From the source comments in `compiler/cmm/Cmm.hs`:
|> Registers live on entry. Note that the set of live
|> registers will be correct in generated C-- code, but
|> not in hand-written C-- code. However,
|> splitAtProcPoints calculates correct liveness
|> information for CmmProcs.
|  
|I would assume that this is an invalid case?
|  
|  - Can the CmmProcs live registers be a strict subset of
|the corresponding CmmCalls?
|  
|This case however seems to be valid case.  However, this
|makes me wonder if we can, and should(?) propagate the
|live register info from the CmmProc to the CmmCall so
|that they match up, and the registers are not kept live
|at the origin of the CmmCall if they aren’t needed?  And
|as such potentially compute anything to put into the
|registers the CmmCall considers live, but the CmmProc
|would ignore anyway?
|  
|  Cheers,
|   Moritz
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs=02%7C01%7Csimonpj%40microsoft.com%7C6009bb0f47a447a4217708d50183ce
|  fa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416587981602708=vII
|  rlKVJa6E%2FBvVz5Sod1c544nw6gsGp54Mlhr7bQ8g%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Determine instance method from class method callsite

[Simon Peyton Jones via ghc-devs]

Did you get a reply?

I’m not 100% certain of your question, but consider the

bar = show 
for some expression e.   In the input to the type type checker the syntax tree 
for the RHS will be something like
HsApp (HsVar “show”) 

(The “show” isn’t really a string, it’s the Name for the class method.)

After typechecking the syntax tree is augmented (or “elaborated”) with type and 
dictionary application.  So in concrete form it might look like
bar = show @Foo dShowFoo 

Because show :: forall a. Show a => a -> String, so show is apply to the type 
of its argument, and then to the dictionary.

In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The 
elaborated syntax tree look like

HsApp (HsWrap  (HsVar “show”))
  

The  part expresses the type and dictionary application. In this case 
it’ll look like
WpEvApp dShowFoo (WpTyApp Foo WpHole)

See the notes with `HsWrapper` in TcEvidence.

Does that help?

It would be great to augment the 
https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info 
(insofar as it doesn’t have it already).  If you augment I can review.  Email 
is quickly lost.

Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Robin Palotai
Sent: 19 September 2017 06:39
To: GHC developers ; haskell 
Subject: Determine instance method from class method callsite

Sorry, I messed up subject and mailing list. Copying to both list now after the 
mistake (wanted only ghc-devs for specificity).

Thanks!

2017-09-19 7:36 GMT+02:00 Robin Palotai 
>:
Hello GHC devs,

Before inventing the wheel, want to check if there is a GHC API way to look up 
the (fully) resolved instance method from a class method.

For example, given a code

data Foo Int deriving Show

bar = show (Foo 3)

when inspecting the Typechecked AST for bar's show call, I would like to get to 
the Name / Id of 'show' of the 'Show' typeclass.

I believe I could use splitHsSigmaTy on the HsType of the function call to get 
the context, and then evaluate the HsWrapper somehow to find out what instance 
dictionary is applied to the class restriction in the context, and then look up 
the instance method from the dictionary..

Two questions:

1) Is there maybe functionality for this?

2) If not, is there any guarantee about the constraint order in the context, at 
the method call? So I could more easily determine which constraint's 
application to look for..

Any hints welcome && Thank you!
Robin

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs