Re: [core libraries] Re: Add taggedTrace to Debug.Trace

[Evan Laforge]

I agree that tags are necessary, and in fact I recently ported my
internal debug library to cabal because now that I'm doing more stuff
with cabal I find life too difficult without my accustomed debug
library.  For reference, it is this, but nothing fancy:
https://github.com/elaforge/el-debug/blob/master/src/EL/Debug.hs

So that's a vote for those things being worth it.  But there are
plenty of little things in there which mean I would still use my own
library, not Debug.Trace, even if it did have a few extra functions.
Such as pretty printing, forcing to avoid interleaved output, timeouts
to avoid hanging, function return value tracing, and probably many
more.  And even after that, since there's no global agreed-upon Pretty
class, I had to remove the Pretty variants, which means it loses a
lot.  And it may seem petty, but since I type them all the time, I'd
want to use my short names, rather than the increasingly long and
clunky ones in Debug.Trace.

So rather than adding little bits to Debug.Trace to nudge it towards
usefulness, maybe it would be better to make your own ideal debug
trace library, and just use that wherever you go.


On Mon, Jun 11, 2018 at 5:18 PM, Yuji Yamamoto
 wrote:
> Can anyone give me more feedback?
> I'm interested especially in my last reply.
>
>
> 2018年6月8日(金) 9:19 Yuji Yamamoto :
>>
>> Almost any formatting will do. At least I never care.
>> I assume those APIs would be used for very ad-hoc use (like the other APIs
>> in Debug.Trace).
>> And debug codes put by such cases are deleted or disabled by NoTrace
>> package in production.
>> I want handy default functions available without batteries.
>> Detailed formatting for debug messages should be configured by
>> third-parties' logging libraries.
>>
>> 2018年6月8日(金) 4:29 Andrew Martin :
>>>
>>> I am -1 on this. Such a function requires making a decision about
>>> formatting. What does a user expect from
>>>
>>> > taggedTraceShowId "meganum" (42 :: Int)
>>>
>>> Any of these are reasonable:
>>>
>>> meganum: 42
>>> meganum [42]
>>> [meganum]: 42
>>>
>>> In different applications I've worked on, I've wanted different flavors
>>> of something like this. Since there's no obvious choice, I don't think base
>>> is a good place for such a function.
>>>
>>> On Thu, Jun 7, 2018 at 12:59 PM, Ben Gamari  wrote:

 Edward Kmett  writes:

 > What different users would do with such a prefix, how to display it,
 > etc. varies just enough that i’m somewhat hesitant to grow the API.
 > I’m a very weak -1. But I’d happily let anybody else on the committee
 > override that if they had a strong preference.
 >
 Right, as I mentioned I'm not sure about the tagging idea. However, I
 have found things of the form `(a -> String) -> a -> a` handy in the
 past.
 Then again, it's pretty trivial to open-code this when needed.

 Cheers,

 - Ben

 --
 You received this message because you are subscribed to the Google
 Groups "haskell-core-libraries" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to haskell-core-libraries+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> --
>>> -Andrew Thaddeus Martin
>>
>>
>>
>> --
>> 山本悠滋
>> twitter: @igrep
>> GitHub: https://github.com/igrep
>> GitLab: https://gitlab.com/igrep
>> Facebook: http://www.facebook.com/igrep
>> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>
>
>
> --
> 山本悠滋
> twitter: @igrep
> GitHub: https://github.com/igrep
> GitLab: https://gitlab.com/igrep
> Facebook: http://www.facebook.com/igrep
> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>
> ___
> 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

Re: Typechecker doesn't preserve HsPar in renamed source.

[Richard Eisenberg]

Great -- and glad to see this getting appropriate attention over there.

Richard

> On Jun 11, 2018, at 11:51 PM, Zubin Duggal  wrote:
> 
> At the time I hadn't modified tcSeq and tcTagToEnum to take HsArgPars into 
> account. I have now done that, and also added a test case.
> 
> I've also submitted the fix to Phab, over here: 
> https://phabricator.haskell.org/D4822 
> 
> On 12 June 2018 at 09:04, Richard Eisenberg  > wrote:
> This looks pretty good to me. What's "in progress" about it?
> 
> I would want to see a comment on the declaration for HsArgPar with an 
> example, and a test case.
> 
> Thanks!
> Richard
> 
>> On Jun 7, 2018, at 6:38 AM, Zubin Duggal > > wrote:
>> 
>> Hello all,
>> 
>> The typechecker doesn't preserve parenthesis that occur at the head of 
>> applications.
>> 
>> This results in some weird SrcSpans in the TypecheckedSource
>> 
>> For example, given code
>> 
>> foo a b c = (bar a) b c
>> 
>> The typechecker will emit an HsApp with head spanning over `bar a) b` and 
>> tail spanning over `c`.
>> Notice that the opening parenthesis is not included.
>> 
>> On the other hand, the renamer will generate the expected SrcSpans that 
>> always include both parenthesis, or neither. This becomes an issue when you 
>> want to associate RenamedSource with its corresponding TypecheckedSource, as 
>> the SrcSpans no longer match and overlap partially.
>> 
>> This occurs due to this line in TcExpr.hs
>> 
>> tcApp m_herald (L _ (HsPar _ fun)) args res_ty
>>   = tcApp m_herald fun args res_ty
>> 
>> I have a work in progress fix here: 
>> https://github.com/wz1000/ghc/commit/3b6db5a35dc8677a7187e349a85ffd51f452452a
>>  
>> 
>> 
>> I have also created a ticket on trac: 
>> https://ghc.haskell.org/trac/ghc/ticket/15242#ticket 
>> 
>> ___
>> 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

Re: Typechecker doesn't preserve HsPar in renamed source.

[Zubin Duggal]

At the time I hadn't modified tcSeq and tcTagToEnum to take HsArgPars into
account. I have now done that, and also added a test case.

I've also submitted the fix to Phab, over here:
https://phabricator.haskell.org/D4822

On 12 June 2018 at 09:04, Richard Eisenberg  wrote:

> This looks pretty good to me. What's "in progress" about it?
>
> I would want to see a comment on the declaration for HsArgPar with an
> example, and a test case.
>
> Thanks!
> Richard
>
> On Jun 7, 2018, at 6:38 AM, Zubin Duggal  wrote:
>
> Hello all,
>
> The typechecker doesn't preserve parenthesis that occur at the head of
> applications.
>
> This results in some weird SrcSpans in the TypecheckedSource
>
> For example, given code
>
> foo a b c = (bar a) b c
>
> The typechecker will emit an HsApp with head spanning over `bar a) b` and
> tail spanning over `c`.
> Notice that the opening parenthesis is not included.
>
> On the other hand, the renamer will generate the expected SrcSpans that
> always include both parenthesis, or neither. This becomes an issue when you
> want to associate RenamedSource with its corresponding TypecheckedSource,
> as the SrcSpans no longer match and overlap partially.
>
> This occurs due to this line in TcExpr.hs
>
> tcApp m_herald (L _ (HsPar _ fun)) args res_ty
>   = tcApp m_herald fun args res_ty
>
> I have a work in progress fix here: https://github.com/wz1000/ghc/commit/
> 3b6db5a35dc8677a7187e349a85ffd51f452452a
>
> I have also created a ticket on trac: https://ghc.haskell.org/trac/
> ghc/ticket/15242#ticket
> ___
> 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

Re: Typechecker doesn't preserve HsPar in renamed source.

[Richard Eisenberg]

This looks pretty good to me. What's "in progress" about it?

I would want to see a comment on the declaration for HsArgPar with an example, 
and a test case.

Thanks!
Richard

> On Jun 7, 2018, at 6:38 AM, Zubin Duggal  wrote:
> 
> Hello all,
> 
> The typechecker doesn't preserve parenthesis that occur at the head of 
> applications.
> 
> This results in some weird SrcSpans in the TypecheckedSource
> 
> For example, given code
> 
> foo a b c = (bar a) b c
> 
> The typechecker will emit an HsApp with head spanning over `bar a) b` and 
> tail spanning over `c`.
> Notice that the opening parenthesis is not included.
> 
> On the other hand, the renamer will generate the expected SrcSpans that 
> always include both parenthesis, or neither. This becomes an issue when you 
> want to associate RenamedSource with its corresponding TypecheckedSource, as 
> the SrcSpans no longer match and overlap partially.
> 
> This occurs due to this line in TcExpr.hs
> 
> tcApp m_herald (L _ (HsPar _ fun)) args res_ty
>   = tcApp m_herald fun args res_ty
> 
> I have a work in progress fix here: 
> https://github.com/wz1000/ghc/commit/3b6db5a35dc8677a7187e349a85ffd51f452452a 
> 
> 
> I have also created a ticket on trac: 
> https://ghc.haskell.org/trac/ghc/ticket/15242#ticket 
> 
> ___
> 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

Re: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened

[Nicolas Frisby]

Whoops, I replied via email instead of commenting on the ticket. I've done
so now. Sorry for the mailing list noise.

On Mon, Jun 11, 2018, 08:21 Nicolas Frisby  wrote:

> That way of saying it clarifies the expectations for me. And doesn't seem
> too burdensome for the plugin author.
>
> Thus I think this ticket could be resolved by updating the documentation.
> (Though I still would like for a plugin to be able to request the flattened
> Wanteds. Separate ticket?)
>
> In particular this sentence in the User Guide
>
> "[The plugin] will be invoked at two points in the constraint solving
> process: after simplification of given constraints, and after unflattening
> of wanted constraints."
>
> would benefit from some elaboration. Specifically, "unflattening of wanted
> constraints" is somewhat ambiguous: until you spelled it out, I was
> thinking that if a constraint is flattened, it doesn't have any flattening
> variables in it. However, I'm inferring here that the jargon is used to
> mean that "unflattening a wanted constraint" only eliminates fmvs, possibly
> leaving fsks behind? That's what I've been confused about (until now, I
> think). Thanks.
>
>
> On Tue, Jun 5, 2018, 01:48 GHC  wrote:
>
>> #15147: Type checker plugin receives Wanteds that are not completely
>> unflattened
>>
>> -+-
>> Reporter:  nfrisby   |Owner:  (none)
>> Type:  bug   |   Status:  new
>> Priority:  normal|Milestone:  8.6.1
>>Component:  Compiler (Type|  Version:  8.4.1
>>   checker)   | Keywords:
>>   Resolution:|  TypeCheckerPlugins
>> Operating System:  Unknown/Multiple  | Architecture:
>>  |  Unknown/Multiple
>>  Type of failure:  None/Unknown  |Test Case:
>>   Blocked By:| Blocking:
>>  Related Tickets:|  Differential Rev(s):
>>Wiki Page:|
>>
>> -+-
>>
>> Comment (by simonpj):
>>
>>  > Perhaps I'm misunderstanding something
>>
>>  I didn't express it very clearly.  As it stands, the Given CFunEqCan's
>>  remain, and hence so do the fsks.  The Wanted CFunEqCans are removed
>>  (currently) along with the fmvs.
>>
>>  So yes, currently Wanteds can contain fsks, whose definition is given by
>> a
>>  CFunEqCan.  I would have thought that most plugins would not find it hard
>>  to deal with that.
>>
>> --
>> Ticket URL: 
>> GHC 
>> The Glasgow Haskell Compiler
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [core libraries] Re: Add taggedTrace to Debug.Trace

[Yuji Yamamoto]

Can anyone give me more feedback?
I'm interested especially in my last reply.


2018年6月8日(金) 9:19 Yuji Yamamoto :

> Almost any formatting will do. At least I never care.
> I assume those APIs would be used for very ad-hoc use (like the other APIs
> in Debug.Trace).
> And debug codes put by such cases are deleted or disabled by NoTrace
>  package in production.
> I want handy default functions available without batteries.
> Detailed formatting for debug messages should be configured by
> third-parties' logging libraries.
>
> 2018年6月8日(金) 4:29 Andrew Martin :
>
>> I am -1 on this. Such a function requires making a decision about
>> formatting. What does a user expect from
>>
>> > taggedTraceShowId "meganum" (42 :: Int)
>>
>> Any of these are reasonable:
>>
>> meganum: 42
>> meganum [42]
>> [meganum]: 42
>>
>> In different applications I've worked on, I've wanted different flavors
>> of something like this. Since there's no obvious choice, I don't think base
>> is a good place for such a function.
>>
>> On Thu, Jun 7, 2018 at 12:59 PM, Ben Gamari  wrote:
>>
>>> Edward Kmett  writes:
>>>
>>> > What different users would do with such a prefix, how to display it,
>>> > etc. varies just enough that i’m somewhat hesitant to grow the API.
>>> > I’m a very weak -1. But I’d happily let anybody else on the committee
>>> > override that if they had a strong preference.
>>> >
>>> Right, as I mentioned I'm not sure about the tagging idea. However, I
>>> have found things of the form `(a -> String) -> a -> a` handy in the
>>> past.
>>> Then again, it's pretty trivial to open-code this when needed.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "haskell-core-libraries" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to haskell-core-libraries+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> -Andrew Thaddeus Martin
>>
>
>
> --
> 山本悠滋
> twitter: @igrep
> GitHub: https://github.com/igrep
> GitLab: https://gitlab.com/igrep
> Facebook: http://www.facebook.com/igrep
> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
>


-- 
山本悠滋
twitter: @igrep
GitHub: https://github.com/igrep
GitLab: https://gitlab.com/igrep
Facebook: http://www.facebook.com/igrep
Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened

[Nicolas Frisby]

That way of saying it clarifies the expectations for me. And doesn't seem
too burdensome for the plugin author.

Thus I think this ticket could be resolved by updating the documentation.
(Though I still would like for a plugin to be able to request the flattened
Wanteds. Separate ticket?)

In particular this sentence in the User Guide

"[The plugin] will be invoked at two points in the constraint solving
process: after simplification of given constraints, and after unflattening
of wanted constraints."

would benefit from some elaboration. Specifically, "unflattening of wanted
constraints" is somewhat ambiguous: until you spelled it out, I was
thinking that if a constraint is flattened, it doesn't have any flattening
variables in it. However, I'm inferring here that the jargon is used to
mean that "unflattening a wanted constraint" only eliminates fmvs, possibly
leaving fsks behind? That's what I've been confused about (until now, I
think). Thanks.

On Tue, Jun 5, 2018, 01:48 GHC  wrote:

> #15147: Type checker plugin receives Wanteds that are not completely
> unflattened
> -+-
> Reporter:  nfrisby   |Owner:  (none)
> Type:  bug   |   Status:  new
> Priority:  normal|Milestone:  8.6.1
>Component:  Compiler (Type|  Version:  8.4.1
>   checker)   | Keywords:
>   Resolution:|  TypeCheckerPlugins
> Operating System:  Unknown/Multiple  | Architecture:
>  |  Unknown/Multiple
>  Type of failure:  None/Unknown  |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:|  Differential Rev(s):
>Wiki Page:|
> -+-
>
> Comment (by simonpj):
>
>  > Perhaps I'm misunderstanding something
>
>  I didn't express it very clearly.  As it stands, the Given CFunEqCan's
>  remain, and hence so do the fsks.  The Wanted CFunEqCans are removed
>  (currently) along with the fmvs.
>
>  So yes, currently Wanteds can contain fsks, whose definition is given by a
>  CFunEqCan.  I would have thought that most plugins would not find it hard
>  to deal with that.
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs