Re: Output language of typechecking pass?

[Richard Eisenberg]

Yes, GitLab supports such a permalink. The problem is that we frequently revise 
Notes as we understand problems better / improve the implementation. So a 
reader might link to a Note from the wiki only to study an old implementation 
that has been superseded.

Richard

> On Dec 28, 2021, at 3:52 PM, Alan & Kim Zimmerman  wrote:
> 
> FYI, it is possible to make a "permalink" on github, which points to the code 
> at a specific commit. Perhaps gitlab has something similar?
> 
> Alan
> 
> On Tue, 28 Dec 2021 at 19:28, Richard Eisenberg  > wrote:
> We could always make a hyperlink to the source code as hosted on GitLab. But 
> I actually argue not to: such links would quickly become outdated, in one of 
> two ways: either we make a permalink, in which case the linked Note text will 
> become outdated; or we make a link to a particular file & line, in which case 
> the Note might move somewhere else. Instead, just by naming the Note title, 
> we have a slightly-harder-to-use link, where you use it by grepping the 
> source code. This is less convenient, but it will stay up-to-date. Until we 
> have better tooling to, say, create an HTML anchor based on a Note, I think 
> this is the best we can do.
> 
> Richard
> 
>> On Dec 28, 2021, at 12:10 PM, Benjamin Redelings 
>> mailto:benjamin.redeli...@gmail.com>> wrote:
>> 
>> I was thinking about the relationship between the wiki and the notes in the 
>> GHC source.
>> 
>> Would it be possible to link directly to [compiler notes] in the GHC source 
>> from the wiki, using hyperlinks?  Right now, I'm seeing references that look 
>> like: (See Note [Constraint flavours].)
>> 
>> (I can see the motivation to include comments in the source, but I also 
>> think that the wiki is more discoverable than the compiler source code.  So, 
>> in the interests of pursuing both approaches, it would be nice to be able to 
>> link to notes FROM the wiki.  I suppose one could include a hyperlink to the 
>> file on github that contains the note...)
>> 
>> I'm not sure how much web infrastructure would be required to make 
>> hyperlinks for notes...
>> 
>> -BenRI
>> 
>> On 11/8/21 5:35 AM, Simon Peyton Jones wrote:
>>> Is there anywhere on the GHC wiki that explains how to interpret this 
>>> output, and says that the type and dictionary applications ARE there, just 
>>> not shown by '-ddump-tc'?
>>> 
>>> Perhaps it would be helpful to add some basic description of what comes out 
>>> of the typechecker to a page like this one? (below)
>>> 
>>> https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/hsc-main 
>>> 
>>> Yes it would!  Would you care to start such a wiki page (a new one; don’t 
>>> just clutter up the one you point to)?You can write down what you know. 
>>>  Don’t worry if you aren’t 100% sure – we can correct it.  And if you 
>>> outright don’t know, leave a “What should I say here?” note.
>>>  
>>> "This late desugaring is somewhat unusual. It is much more common to 
>>> desugar the program before typechecking, or renaming, because that presents 
>>> the renamer and typechecker with a much smaller language to deal with. 
>>> However, GHC's organisation means that
>>> 
>>> This note is now slightly out of date.  We are now, very carefully, doing 
>>> some desugaring before typechecking.  See
>>> Note [Handling overloaded and rebindable constructs]  in GHC.Rename.Expr
>>> Note [Rebindable syntax and HsExpansion] in GHC.Hs.Expr
>>>  
>>> You can and should point to these and similar Notes from the wiki page you 
>>> write.  Indeed there may be some part of what you write that would be 
>>> better framed as Note in GHC’s source code.
>>>  
>>> Thanks!
>>>  
>>> Simon
>>>  
>>> PS: I am leaving Microsoft at the end of November 2021, at which point 
>>> simo...@microsoft.com  will cease to work.  
>>> Use simon.peytonjo...@gmail.com  
>>> instead.  (For now, it just forwards to simo...@microsoft.com 
>>> .)
>>>  
>>> From: ghc-devs  
>>>  On Behalf Of Benjamin Redelings
>>> Sent: 08 November 2021 13:12
>>> To: Richard Eisenberg  
>>> Cc: ghc-devs@haskell.org 
>>> Subject: Re: Output language of typechecking pass?
>>>  
>>> Hi,
>>> 
>>>  
>>> Questions:
>>>  
>>> 1. It seems like this separation is actually necessary, in order to apply 
>>> generalization only to let arguments written by the programmer, and not to 
>>> let 

Re: Output language of typechecking pass?

[Alan & Kim Zimmerman]

FYI, it is possible to make a "permalink" on github, which points to the
code at a specific commit. Perhaps gitlab has something similar?

Alan

On Tue, 28 Dec 2021 at 19:28, Richard Eisenberg  wrote:

> We could always make a hyperlink to the source code as hosted on GitLab.
> But I actually argue not to: such links would quickly become outdated, in
> one of two ways: either we make a permalink, in which case the linked Note
> text will become outdated; or we make a link to a particular file & line,
> in which case the Note might move somewhere else. Instead, just by naming
> the Note title, we have a slightly-harder-to-use link, where you use it by
> grepping the source code. This is less convenient, but it will stay
> up-to-date. Until we have better tooling to, say, create an HTML anchor
> based on a Note, I think this is the best we can do.
>
> Richard
>
> On Dec 28, 2021, at 12:10 PM, Benjamin Redelings <
> benjamin.redeli...@gmail.com> wrote:
>
> I was thinking about the relationship between the wiki and the notes in
> the GHC source.
>
> Would it be possible to link directly to [compiler notes] in the GHC
> source from the wiki, using hyperlinks?  Right now, I'm seeing references
> that look like: (See Note [Constraint flavours].)
>
> (I can see the motivation to include comments in the source, but I also
> think that the wiki is more discoverable than the compiler source code.
> So, in the interests of pursuing both approaches, it would be nice to be
> able to link to notes FROM the wiki.  I suppose one could include a
> hyperlink to the file on github that contains the note...)
>
> I'm not sure how much web infrastructure would be required to make
> hyperlinks for notes...
>
> -BenRI
> On 11/8/21 5:35 AM, Simon Peyton Jones wrote:
>
> Is there anywhere on the GHC wiki that explains how to interpret this
> output, and says that the type and dictionary applications ARE there, just
> not shown by '-ddump-tc'?
>
> Perhaps it would be helpful to add some basic description of what comes
> out of the typechecker to a page like this one? (below)
>
>
> https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/hsc-main
> 
> Yes it would!  Would you care to start such a wiki page (a new one; don’t
> just clutter up the one you point to)?You can write down what you
> know.  Don’t worry if you aren’t 100% sure – we can correct it.  And if you
> outright don’t know, leave a “What should I say here?” note.
>
>
> "This late desugaring is somewhat unusual. It is much more common to
> desugar the program before typechecking, or renaming, because that presents
> the renamer and typechecker with a much smaller language to deal with.
> However, GHC's organisation means that
> This note is now slightly out of date.  We are now, very carefully, doing
> some desugaring *before* typechecking.  See
>
>- Note [Handling overloaded and rebindable constructs]  in
>GHC.Rename.Expr
>- Note [Rebindable syntax and HsExpansion] in GHC.Hs.Expr
>
>
> You can and should point to these and similar Notes from the wiki page you
> write.  Indeed there may be some part of what you write that would be
> better framed as Note in GHC’s source code.
>
> Thanks!
>
> Simon
>
> PS: I am leaving Microsoft at the end of November 2021, at which point
> simo...@microsoft.com will cease to work.  Use simon.peytonjo...@gmail.com
>  instead.  (For now, it just forwards to simo...@microsoft.com.)
>
> *From:* ghc-devs 
>  *On Behalf Of *Benjamin Redelings
> *Sent:* 08 November 2021 13:12
> *To:* Richard Eisenberg  
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Output language of typechecking pass?
>
>
> Hi,
>
>
>
> Questions:
>
>
>
> 1. It seems like this separation is actually necessary, in order to apply 
> generalization only to let arguments written by the programmer, and not to 
> let bindings introduced during desugaring. Is that right?
>
>
>
> I don't think so. That is, if we did it all in one pass, I still think we 
> could get generalization right.
>
> I guess I asked this question wrong.  I mean to say, if we did the two
> passes in the reverse order (desugaring first, followed by typechecking),
> that would not work, right?
>
> As the wiki says:
>
> "This late desugaring is somewhat unusual. It is much more common to
> desugar the program before typechecking, or renaming, because that presents
> the renamer and typechecker with a much smaller language to deal with.
> However, GHC's organisation means that
>
>- error messages can display precisely the syntax that the user wrote;
>and
>- 

Re: Output language of typechecking pass?

[Richard Eisenberg]

We could always make a hyperlink to the source code as hosted on GitLab. But I 
actually argue not to: such links would quickly become outdated, in one of two 
ways: either we make a permalink, in which case the linked Note text will 
become outdated; or we make a link to a particular file & line, in which case 
the Note might move somewhere else. Instead, just by naming the Note title, we 
have a slightly-harder-to-use link, where you use it by grepping the source 
code. This is less convenient, but it will stay up-to-date. Until we have 
better tooling to, say, create an HTML anchor based on a Note, I think this is 
the best we can do.

Richard

> On Dec 28, 2021, at 12:10 PM, Benjamin Redelings 
>  wrote:
> 
> I was thinking about the relationship between the wiki and the notes in the 
> GHC source.
> 
> Would it be possible to link directly to [compiler notes] in the GHC source 
> from the wiki, using hyperlinks?  Right now, I'm seeing references that look 
> like: (See Note [Constraint flavours].)
> 
> (I can see the motivation to include comments in the source, but I also think 
> that the wiki is more discoverable than the compiler source code.  So, in the 
> interests of pursuing both approaches, it would be nice to be able to link to 
> notes FROM the wiki.  I suppose one could include a hyperlink to the file on 
> github that contains the note...)
> 
> I'm not sure how much web infrastructure would be required to make hyperlinks 
> for notes...
> 
> -BenRI
> 
> On 11/8/21 5:35 AM, Simon Peyton Jones wrote:
>> Is there anywhere on the GHC wiki that explains how to interpret this 
>> output, and says that the type and dictionary applications ARE there, just 
>> not shown by '-ddump-tc'?
>> 
>> Perhaps it would be helpful to add some basic description of what comes out 
>> of the typechecker to a page like this one? (below)
>> 
>> https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/hsc-main 
>> 
>> Yes it would!  Would you care to start such a wiki page (a new one; don’t 
>> just clutter up the one you point to)?You can write down what you know.  
>> Don’t worry if you aren’t 100% sure – we can correct it.  And if you 
>> outright don’t know, leave a “What should I say here?” note.
>>  
>> "This late desugaring is somewhat unusual. It is much more common to desugar 
>> the program before typechecking, or renaming, because that presents the 
>> renamer and typechecker with a much smaller language to deal with. However, 
>> GHC's organisation means that
>> 
>> This note is now slightly out of date.  We are now, very carefully, doing 
>> some desugaring before typechecking.  See
>> Note [Handling overloaded and rebindable constructs]  in GHC.Rename.Expr
>> Note [Rebindable syntax and HsExpansion] in GHC.Hs.Expr
>>  
>> You can and should point to these and similar Notes from the wiki page you 
>> write.  Indeed there may be some part of what you write that would be better 
>> framed as Note in GHC’s source code.
>>  
>> Thanks!
>>  
>> Simon
>>  
>> PS: I am leaving Microsoft at the end of November 2021, at which point 
>> simo...@microsoft.com  will cease to work.  
>> Use simon.peytonjo...@gmail.com  
>> instead.  (For now, it just forwards to simo...@microsoft.com 
>> .)
>>  
>> From: ghc-devs  
>>  On Behalf Of Benjamin Redelings
>> Sent: 08 November 2021 13:12
>> To: Richard Eisenberg  
>> Cc: ghc-devs@haskell.org 
>> Subject: Re: Output language of typechecking pass?
>>  
>> Hi,
>> 
>>  
>> Questions:
>>  
>> 1. It seems like this separation is actually necessary, in order to apply 
>> generalization only to let arguments written by the programmer, and not to 
>> let bindings introduced during desugaring. Is that right?
>>  
>> I don't think so. That is, if we did it all in one pass, I still think we 
>> could get generalization right.
>> I guess I asked this question wrong.  I mean to say, if we did the two 
>> passes in the reverse order (desugaring first, followed by typechecking), 
>> that would not work, right?
>> 
>> As the wiki says:
>> 
>> "This late desugaring is somewhat unusual. It is much more common to desugar 
>> the program before typechecking, or renaming, because that presents the 
>> renamer and typechecker with a much smaller language to deal with. However, 
>> GHC's organisation means that
>> 
>> error messages can display precisely the syntax that the 

Re: Output language of typechecking pass?

[Benjamin Redelings]

I was thinking about the relationship between the wiki and the notes in 
the GHC source.


Would it be possible to link directly to [compiler notes] in the GHC 
source from the wiki, using hyperlinks?  Right now, I'm seeing 
references that look like: (See |Note [Constraint flavours]|.)


(I can see the motivation to include comments in the source, but I also 
think that the wiki is more discoverable than the compiler source code.  
So, in the interests of pursuing both approaches, it would be nice to be 
able to link to notes FROM the wiki.  I suppose one could include a 
hyperlink to the file on github that contains the note...)


I'm not sure how much web infrastructure would be required to make 
hyperlinks for notes...


-BenRI

On 11/8/21 5:35 AM, Simon Peyton Jones wrote:


Is there anywhere on the GHC wiki that explains how to interpret this 
output, and says that the type and dictionary applications ARE there, 
just not shown by '-ddump-tc'?


Perhaps it would be helpful to add some basic description of what 
comes out of the typechecker to a page like this one? (below)


https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/hsc-main 



Yes it would!  Would you care to start such a wiki page (a new one; 
don’t just clutter up the one you point to)?    You can write down 
what you know.  Don’t worry if you aren’t 100% sure – we can correct 
it.  And if you outright don’t know, leave a “What should I say here?” 
note.


"This late desugaring is somewhat unusual. It is much more common to 
desugar the program before typechecking, or renaming, because that 
presents the renamer and typechecker with a much smaller language to 
deal with. However, GHC's organisation means that


This note is now slightly out of date.  We are now, very carefully, 
doing some desugaring *before* typechecking.  See


  * Note [Handling overloaded and rebindable constructs]  in
GHC.Rename.Expr
  * Note [Rebindable syntax and HsExpansion] in GHC.Hs.Expr

You can and should point to these and similar Notes from the wiki page 
you write.  Indeed there may be some part of what you write that would 
be better framed as Note in GHC’s source code.


Thanks!

Simon

PS: I am leaving Microsoft at the end of November 2021, at which point 
simo...@microsoft.com  will cease to 
work.  Use simon.peytonjo...@gmail.com 
 instead.  (For now, it just 
forwards to simo...@microsoft.com.)


*From:*ghc-devs  *On Behalf Of *Benjamin 
Redelings

*Sent:* 08 November 2021 13:12
*To:* Richard Eisenberg 
*Cc:* ghc-devs@haskell.org
*Subject:* Re: Output language of typechecking pass?

Hi,

Questions:

1. It seems like this separation is actually necessary, in order to 
apply generalization only to let arguments written by the programmer, and not 
to let bindings introduced during desugaring. Is that right?

I don't think so. That is, if we did it all in one pass, I still think we 
could get generalization right.

I guess I asked this question wrong.  I mean to say, if we did the two 
passes in the reverse order (desugaring first, followed by 
typechecking), that would not work, right?


As the wiki says:

"This late desugaring is somewhat unusual. It is much more common to 
desugar the program before typechecking, or renaming, because that 
presents the renamer and typechecker with a much smaller language to 
deal with. However, GHC's organisation means that


  * error messages can display precisely the syntax that the user
wrote; and
  * desugaring is not required to preserve type-inference properties.

"

2. Does the output of type checking contain type lambdas?

Yes. See below.

3. Does the type checking pass determine where to add dictionary 
arguments?

Yes. See below.

4. Are there any other resources I should be looking at?

Yes. You want to enable -fprint-typechecker-elaboration (and possible 
-fprint-explicit-coercions). With the former, you get to see all this stuff 
you're looking for. It's normally suppressed so that the output resembles the 
user's code.

I hope this helps!

Richard

Hmm... so, I think I see how this works now.  I don't think 
'-fprint-explicit-coercions' does anything here though.


$ ghc -ddump-tc Test2.hs -fprint-typechecker-elaboration

...

AbsBinds [a_a2hp] [$dNum_a2hB]
  {Exports: [g <= g_a2hz
   wrap: <>]
   Exported types: g :: forall a. Num a => a -> a -> a
   [LclId]
   Binds: g x_aYk y_aYl = (y_aYl * x_aYk) + 1
   

What's the benefit of taking "do" blocks apart? Is there a way to turn that off?

[Erdi, Gergo via ghc-devs]

PUBLIC

Hi,

I'm seeing 'do' blocks getting taking apart into top-level definitions, so e.g.

main = do
  some complicated expression 1
  some complicated expression 2

is compiled into

sat_sKv = some complicated expression 1
sat_sKw = \_ -> some complicated expression 2
main = bindIO sat_sKv sat_sKw

This seems to happen regardless of any common subexpressions, i.e. it is not 
the case that sat_sKv or sat_sKw are used anywhere else.

What is the intended benefit of this floating-out? Is there a particular 
Core-to-Core pass that causes this? Is it possible to turn it off?

Thanks,
Gergo

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, 
Standard Chartered Bank and their subsidiaries (the "Group"), information on 
the regulatory standards we adhere to and how it may affect you can be found in 
our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory 
Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and 
contains any market commentary, the market commentary has been prepared by the 
sales and/or trading desk of Standard Chartered Bank or its affiliate. It is 
not and does not constitute research material, independent research, 
recommendation or financial advice. Any market commentary is for information 
purpose only and shall not be relied on for any other purpose and is subject to 
the relevant disclaimers available at https: 
//www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains 
any research materials prepared by members of the team, the research material 
is for information purpose only and shall not be relied on for any other 
purpose, and is subject to the relevant disclaimers available at https: 
//research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign the term 
sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
important information with respect to derivative products.___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Measuring thread cpu time (using bound threads)

[Harendra Kumar]

Hi GHC devs,

I want to measure the CPU time spent in a particular Haskell thread across
thread yield points. I am assuming Haskell threads do not keep track of per
thread cpu time. Therefore, to measure it I have to use the thread cpu
clock (CLOCK_THREAD_CPUTIME_ID) provided by the OS (Linux). But Haskell
threads can keep jumping across multiple OS threads so the OS thread's CPU
time cannot be used reliably.

To solve that issue I thought I could use bound threads. From the
documentation it sounded like bound threads are exclusively bound to a
particular OS thread so we can get thread cpu time from the OS and use it.

However, if I print the thread id for a bound thread using "gettid" (OS
thread id on Linux) or using "pthread_self" (pthread id), both these thread
ids are changing for the same Haskell thread which is a bound thread. Is
that expected, or am I doing something wrong?

My questions:

* Are bound threads really bound to a particular OS thread or they can use
multiple OS threads for executing Haskell code, and only use a fixed OS
thread for FFI code?
* Is there a way to make this work? Can we obtain the thread cpu time
reliably across thread yield points? Is there a way to really bind Haskell
threads to OS threads?
* Is there a better or alternative way to get the thread CPU time?

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

RE: [External] Re: Source locations from Core

[Erdi, Gergo via ghc-devs]

PUBLIC

Thank you, this looks exactly like what I'm looking for. Now I'll just have to 
try it on larger examples to see how approximate it is 

-Original Message-
From: Matthew Pickering  
Sent: Tuesday, December 28, 2021 10:36 AM
To: Erdi, Gergo 
Cc: GHC 
Subject: [External] Re: Source locations from Core

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails. Always report 
suspicious emails using the Report As Phishing button in Outlook to protect the 
Bank and our clients.


Hi Gergo,

Source Notes are what you are looking for. Currently the only way to enable 
them is to either use `-g` or `-finfo-table-map`. The result will be core which 
contains nodes which attempt to describe where the core expression came from, 
it's not perfect though!

See Section 5.4 - 
https://clicktime.symantec.com/3QgzZCkQPV23ts2BtD4WH4Z7VN?u=https%3A%2F%2Fetheses.whiterose.ac.uk%2F8321%2F1%2Fthesis.pdf

Matt

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, 
Standard Chartered Bank and their subsidiaries (the "Group"), information on 
the regulatory standards we adhere to and how it may affect you can be found in 
our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory 
Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and 
contains any market commentary, the market commentary has been prepared by the 
sales and/or trading desk of Standard Chartered Bank or its affiliate. It is 
not and does not constitute research material, independent research, 
recommendation or financial advice. Any market commentary is for information 
purpose only and shall not be relied on for any other purpose and is subject to 
the relevant disclaimers available at https: 
//www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains 
any research materials prepared by members of the team, the research material 
is for information purpose only and shall not be relied on for any other 
purpose, and is subject to the relevant disclaimers available at https: 
//research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign the term 
sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
important information with respect to derivative products.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Source locations from Core

[Matthew Pickering]

Hi Gergo,

Source Notes are what you are looking for. Currently the only way to
enable them is to either use `-g` or `-finfo-table-map`. The result
will be core which contains nodes which attempt to describe where the
core expression came from, it's not perfect though!

See Section 5.4 - https://etheses.whiterose.ac.uk/8321/1/thesis.pdf

Matt

On Tue, Dec 28, 2021 at 9:14 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I’m looking for ways to map Core fragments back to source locations.
>
>
>
> I see there is an annotated version of Core in `GHC/Core.hs` called 
> `AnnExpr`, which I could see being useful for this if I set the annotation 
> type to `SrcSpan`, but that’s not what I get out of GHC’s desugarer, 
> simplifier or tidier.
>
>
>
> If there’s no built-in mechanism for this, my only idea would be to create a 
> HsExpr-to-HsExpr transformation that wraps every node in a call that is 
> opaque enough to be persisted through Core-to-Core transformations but still 
> transparent enough that it doesn’t block optimization opportunities. Is that 
> even possible?
>
>
>
> Alternatively, would it make it easer if I was content with only getting 
> source locations for variable occurrences?
>
>
>
> Thanks,
>
>Gergo
>
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the research 
> material is for information purpose only and shall not be relied on for any 
> other purpose, and is subject to the relevant disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by 
> responding affirmatively to this e-mail, you agree that you have understood 
> the terms and conditions in the attached term sheet and evaluated the merits 
> and risks of the transaction. We may at times also request you to sign the 
> term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
> important information with respect to derivative products.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Source locations from Core

[Erdi, Gergo via ghc-devs]

PUBLIC

Hi,

I'm looking for ways to map Core fragments back to source locations.

I see there is an annotated version of Core in `GHC/Core.hs` called `AnnExpr`, 
which I could see being useful for this if I set the annotation type to 
`SrcSpan`, but that's not what I get out of GHC's desugarer, simplifier or 
tidier.

If there's no built-in mechanism for this, my only idea would be to create a 
HsExpr-to-HsExpr transformation that wraps every node in a call that is opaque 
enough to be persisted through Core-to-Core transformations but still 
transparent enough that it doesn't block optimization opportunities. Is that 
even possible?

Alternatively, would it make it easer if I was content with only getting source 
locations for variable occurrences?

Thanks,
   Gergo

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, 
Standard Chartered Bank and their subsidiaries (the "Group"), information on 
the regulatory standards we adhere to and how it may affect you can be found in 
our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory 
Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and 
contains any market commentary, the market commentary has been prepared by the 
sales and/or trading desk of Standard Chartered Bank or its affiliate. It is 
not and does not constitute research material, independent research, 
recommendation or financial advice. Any market commentary is for information 
purpose only and shall not be relied on for any other purpose and is subject to 
the relevant disclaimers available at https: 
//www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains 
any research materials prepared by members of the team, the research material 
is for information purpose only and shall not be relied on for any other 
purpose, and is subject to the relevant disclaimers available at https: 
//research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign the term 
sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
important information with respect to derivative products.___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs