Re: Do we have free bits in the info pointer itself?

[Ryan Newton]

>
> What did you intend to use the high bits for?
>

Nothing right now.  Just speculation.

I was actually pondering how our headers are rather svelte compared to many
languages.  Java, for instance, saves a full word for a hash.

There are endless bits of metadata to speculate about...

   - whether or not the heap object is frozen to disallow further
   modification (e.g. for MutVars)
   - whether or not the heap object is part of a contiguous CNF
   - a flag to invoke some alternate GC behavior
   - metadata to avoid dereferencing the info table pointer in some
   circumstances (common type tags?)
   - you could even index 2^16 per-type values that live off of the info
   table

But most likely it would have to be something that would give across the
board perf improvements that would pay for the extra cost in masking.  Good
point re: HW prefetching.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Thoughts on CallStack and withFrozenCallStack

[Edward Z. Yang]

So, I also experimented with setting up this type alias in our
Prelude:

type IO a = HasCallStack => Prelude.IO a

It hasn't caused many type checking errors, but here are some
observations:

- It can cause a lot of redundant constraint warnings.
  Often with good reason (sometimes, it indicates somewhere that
  could use the call stack profitably, but isn't at the moment.)
  In cases where it doesn't, I've been suppressing the
  message with "_ = callStack", which works well enough :)

- When interoperating with functions like 'bracket' which take
  an IO action as an argument, I often need to take
  the type "a -> HasCallStack => Prelude.IO b" into
  "a -> Prelude.IO b" (so that I can use the function
  defined in base.)  This function lets me do the
  conversion:

withLexicalCallStack :: (a -> WithCallStack (IO b)) -> WithCallStack (a 
-> IO b)
withLexicalCallStack f =
let stk = ?callStack
in \x -> let ?callStack = stk in f x

  I'm obviously happy to bikeshed names.

- I don't think adding implicit parameters in this way can ever
  cause us to lose tail-call optimization, but the CallStack
  might grow really big. I guess there isn't any pruning done?
  Essentially, you have to be very careful about IO actions which
  call themselves in loops.

Also, here are some responses to Eric's message:

Excerpts from Eric Seidel's message of 2016-09-07 18:14:16 -0700:
> Inside debug, the top element of the callStack should be the call-site
> of debug, which should be exactly what you want. (NB this is new
> behavior as of GHC 8.0.1, in GHC 7.10.2 you would get an extra frame for
> the occurrence of ?callStack)

Yes, you are right!

> Indeed, this sounds useful. The approach I recently took with adding
> CallStacks to logs was to have the internal functions (eg formatting and
> actually printing the logs) take an *explicit* CallStack, and have the
> external functions take an *implicit* CallStack. Thus the internal
> functions are excluded from the stack. But this does give us slightly
> less reuse as, in your example, you couldn't implement pprDebug in terms
> of debug if you also want to export debug.

Yes, that workaround does work, but I don't like it!

> Good point! Another way this could be useful is if you happen to have a
> frozen CallStack already in-scope at the call-site of debug/pprDebug. In
> that scenario, the call-site of the logging function would be lost, and
> you'd end up printing whatever location was at the top of the frozen
> stack, which would be quite confusing!

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

Re: Do we have free bits in the info pointer itself?

[Reid Barton]

Good point. Also

* the high bits are free now, but they may not be free forever (though
that's not a great reason to avoid using them in the meantime)

* masking off the high bits when entering is rather expensive, at
least in code size, compared to a simple "jmp *%rax" or especially
"jmp *symb", which appears at the end of almost every Haskell function

* modifying the low bits of a pointer will leave it pointing at the
same cache line, so the hardware prefetcher may decide to prefetch the
contents (hopefully at an appropriate time) while modifying the high
bits will make it not look like a pointer at all. But it's hard to
know how much we currently gain from hardware prefetching, if
anything.

Certainly these downsides are not necessarily deal-breakers, as
demonstrated by NaN-boxing as used in major JavaScript engines.

What did you intend to use the high bits for?

Regards,
Reid Barton

On Wed, Sep 7, 2016 at 11:16 PM, Edward Kmett  wrote:
> Mostly just that GHC still works on 32 bit platforms.
>
> -Edward
>
> On Wed, Sep 7, 2016 at 5:32 PM, Ryan Newton  wrote:
>>
>> Our heap object header is one word -- an info table pointer.
>>
>> Well, a 64 bit info table pointer leaves *at least* 16 high bits inside
>> the object header for other purposes, right?
>>
>> Is there any problem with using these other than having to mask the info
>> table pointer each time it is dereferenced?
>>
>> Thanks,
>>   -Ryan
>>
>>
>> ___
>> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Do we have free bits in the info pointer itself?

[Edward Kmett]

Mostly just that GHC still works on 32 bit platforms.

-Edward

On Wed, Sep 7, 2016 at 5:32 PM, Ryan Newton  wrote:

> Our heap object header is one word -- an info table pointer
> 
> .
>
> Well, a 64 bit info table pointer leaves *at least* 16 high bits inside
> the object header for other purposes, right?
>
> Is there any problem with using these other than having to mask the info
> table pointer each time it is dereferenced?
>
> Thanks,
>   -Ryan
>
>
> ___
> 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: Feature request bounty

[Ömer Sinan Ağacan]

Simon,

As far as I understand we want to do these two transformations:

(when D is a newtype-like data type constructor)


First:
D arg1 arg2 ... argN
==>
nv_arg (where nv_arg is the only non-void argument)

(but we somehow need to bind other args or do substitution. If we do this
Stg though we don't need to bind those args as unarise doesn't care about
what a void argument is as long as it's void it gets rid of it and it can
check void-ness by looking at Id's type)

Second:
case  of
  D arg1 arg2 ... argN -> 
==>
let arg1 = ...
arg2 = ...
arg3 = ...
 in 
 (we know only one of these args will be non-void, but all of them should be
 bound as they can be referred in )

Am I right?

I think if we do this in Stg we lose some optimization opportunities and
generate ugly code. For example, if the first transformation happens in a
let-binding RHS maybe simplifier decides to inline it as it can't duplicate
work after the transformation. Similarly it can decide to inline the non-void
argument after second transformation which may lead to further optimizations
etc.

For an example of an ugly code, suppose we had this:

case  of
  D (T x) -> 

in Stg this looks like

case  of
  D v -> case v of
   T x -> 

So now if we do the second transformation we get

let v =  in
case v of
  T x -> 

but ideally we'd get

case  of
  T x -> 

I think simplifier would be able to do this after the second transformation.
Am I making any sense?

I have no idea how to do this in the simplifier without losing type safety
though...

Are these two transformations also what you had in mind or do you have something
else?

- Omer

2016-09-07 16:58 GMT-04:00 David Feuer :
> I can't guarantee I'll be able to understand things well enough to
> take your advice, but I'd be willing to give it a shot. Where would be
> the right place to stick this? I am not at all familiar with the GHC
> code generation system. Also, what might I have to do to avoid forcing
> the same object repeatedly? If I have multiple such constructors, and
> someone does
>
> case x of
>   Con1 (Con2 (Con3 (Con4 y))) -> e
>
> I want to smash this down to something that looks like
>
> case x of y {
>   _ -> e }
>
> Do I need to worry about this, or will some later C-- pass take care of it?
>
> On Wed, Sep 7, 2016 at 4:46 PM, Simon Peyton Jones
>  wrote:
>> I can advise about how (see comment:9 of #1965).  I can only see how to do 
>> it in an un-typed way in the back end.
>>
>> Simon
>>
>> | -Original Message-
>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David
>> | Feuer
>> | Sent: 07 September 2016 19:33
>> | To: ghc-devs 
>> | Subject: Feature request bounty
>> |
>> | I'd like to place a small bounty on
>> | https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS .
>> |
>> | If someone implements this request by GHC 8.2, I will buy them 24 bottles
>> | of high-end root beer (e.g., Maine Root) or something of similar value
>> | agreeable to both parties. (*)
>> |
>> | Thanks,
>> | David Feuer
>> |
>> | (*) Recipient responsible for customs/duty/taxes/shipping fees beyond
>> | US$10.
>> | ___
>> | ghc-devs mailing list
>> | ghc-devs@haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.hask
>> | ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>> | devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e4408d3d74
>> | d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636088699768302440&sda
>> | ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d
> ___
> 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: Thoughts on CallStack and withFrozenCallStack

[Eric Seidel]

On Wed, Sep 7, 2016, at 15:10, Edward Z. Yang wrote:
> I've been adding CallStack to Cabal's source code, and I noticed
> a common pattern that doesn't seem to be supported by the GHC.Stack
> API.
> 
> Imagine I'm writing a general purpose logging function:
> 
> debug :: Verbosity -> String -> IO ()
> 
> I'd like this function to print out the SrcLoc of the person who
> called; as an additional requirement, I only want to print the
> top-most stack frame by default (someone can ask for the full
> stack if they really want to).
> 
> If I look at callStack, it is going to contain a stack frame for debug
> itself. That's not so great; the obvious way to fix this is to pop off
> the irrelevant frame manually.  

Inside debug, the top element of the callStack should be the call-site
of debug, which should be exactly what you want. (NB this is new
behavior as of GHC 8.0.1, in GHC 7.10.2 you would get an extra frame for
the occurrence of ?callStack)

> But now suppose that I have a pprDebug
> which itself calls debug.  I don't want pprDebug to show up in the stack
> frame!
> 
> Declaratively, I want to say, "Please don't add me to the call stack",
> at the function *definition*, not the call-site (which is what
> withFrozenCallStack) gives me.  Does this seem like a reasonable request?

Indeed, this sounds useful. The approach I recently took with adding
CallStacks to logs was to have the internal functions (eg formatting and
actually printing the logs) take an *explicit* CallStack, and have the
external functions take an *implicit* CallStack. Thus the internal
functions are excluded from the stack. But this does give us slightly
less reuse as, in your example, you couldn't implement pprDebug in terms
of debug if you also want to export debug.

> I have several other ways to do this:
> 
> - You could just use withFrozenCallStack at the definition site.
>   Then when pprDebug calls debug, debug will get the call stack that
>   pprDebug had; thus, there will always only be one irrelevant frame
>   to pop off.
> 
> - One problem with using withFrozenCallStack is that you *do* lose
>   useful trace information, which you kind of might actually want
>   if you are being verbose.  So it almost seems like, the frozen
>   API should still *push* frames, but just not make them visible
>   by default.

Good point! Another way this could be useful is if you happen to have a
frozen CallStack already in-scope at the call-site of debug/pprDebug. In
that scenario, the call-site of the logging function would be lost, and
you'd end up printing whatever location was at the top of the frozen
stack, which would be quite confusing!

Thanks for the comments!
Eric
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thoughts on CallStack and withFrozenCallStack

[Edward Z. Yang]

I've been adding CallStack to Cabal's source code, and I noticed
a common pattern that doesn't seem to be supported by the GHC.Stack
API.

Imagine I'm writing a general purpose logging function:

debug :: Verbosity -> String -> IO ()

I'd like this function to print out the SrcLoc of the person who
called; as an additional requirement, I only want to print the
top-most stack frame by default (someone can ask for the full
stack if they really want to).

If I look at callStack, it is going to contain a stack frame for debug
itself. That's not so great; the obvious way to fix this is to pop off
the irrelevant frame manually.  But now suppose that I have a pprDebug
which itself calls debug.  I don't want pprDebug to show up in the stack
frame!

Declaratively, I want to say, "Please don't add me to the call stack",
at the function *definition*, not the call-site (which is what
withFrozenCallStack) gives me.  Does this seem like a reasonable request?

I have several other ways to do this:

- You could just use withFrozenCallStack at the definition site.
  Then when pprDebug calls debug, debug will get the call stack that
  pprDebug had; thus, there will always only be one irrelevant frame
  to pop off.

- One problem with using withFrozenCallStack is that you *do* lose
  useful trace information, which you kind of might actually want
  if you are being verbose.  So it almost seems like, the frozen
  API should still *push* frames, but just not make them visible
  by default.

- Something that does NOT work is having functions edit the call
  stack to remove themselves. There's no way to tell if the stack
  is frozen or not, and thus no way to tell if you are actually
  on the stack (and need to remove it.)

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

Do we have free bits in the info pointer itself?

[Ryan Newton]

Our heap object header is one word -- an info table pointer
.

Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the
object header for other purposes, right?

Is there any problem with using these other than having to mask the info
table pointer each time it is dereferenced?

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

Re: Feature request bounty

[David Feuer]

I can't guarantee I'll be able to understand things well enough to
take your advice, but I'd be willing to give it a shot. Where would be
the right place to stick this? I am not at all familiar with the GHC
code generation system. Also, what might I have to do to avoid forcing
the same object repeatedly? If I have multiple such constructors, and
someone does

case x of
  Con1 (Con2 (Con3 (Con4 y))) -> e

I want to smash this down to something that looks like

case x of y {
  _ -> e }

Do I need to worry about this, or will some later C-- pass take care of it?

On Wed, Sep 7, 2016 at 4:46 PM, Simon Peyton Jones
 wrote:
> I can advise about how (see comment:9 of #1965).  I can only see how to do it 
> in an un-typed way in the back end.
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David
> | Feuer
> | Sent: 07 September 2016 19:33
> | To: ghc-devs 
> | Subject: Feature request bounty
> |
> | I'd like to place a small bounty on
> | https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS .
> |
> | If someone implements this request by GHC 8.2, I will buy them 24 bottles
> | of high-end root beer (e.g., Maine Root) or something of similar value
> | agreeable to both parties. (*)
> |
> | Thanks,
> | David Feuer
> |
> | (*) Recipient responsible for customs/duty/taxes/shipping fees beyond
> | US$10.
> | ___
> | ghc-devs mailing list
> | ghc-devs@haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.hask
> | ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> | devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e4408d3d74
> | d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636088699768302440&sda
> | ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Feature request bounty

[Simon Peyton Jones via ghc-devs]

I can advise about how (see comment:9 of #1965).  I can only see how to do it 
in an un-typed way in the back end.

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David
| Feuer
| Sent: 07 September 2016 19:33
| To: ghc-devs 
| Subject: Feature request bounty
| 
| I'd like to place a small bounty on
| https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS .
| 
| If someone implements this request by GHC 8.2, I will buy them 24 bottles
| of high-end root beer (e.g., Maine Root) or something of similar value
| agreeable to both parties. (*)
| 
| Thanks,
| David Feuer
| 
| (*) Recipient responsible for customs/duty/taxes/shipping fees beyond
| US$10.
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.hask
| ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e4408d3d74
| d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636088699768302440&sda
| ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Custom warning suppression

[Elliot Cameron]

I would love this. Especially if we then added "partial" warnings to the
many Prelude/base functions that fit this description.

On Wed, Sep 7, 2016 at 11:09 AM, Richard Eisenberg 
wrote:

> Seems reasonable and useful to me. Is this a good use of the process here?
> https://github.com/ghc-proposals/ghc-proposals
>
> On Sep 7, 2016, at 10:39 AM, David Feuer  wrote:
>
> Currently, the only way to suppress custom warnings and deprecations is
> with -fno-warn-warnings-deprecations, which is a rather large hammer. I
> see two ways we can improve this, and I propose that we should do both.
>
> 1. Per-binding suppression
>
> Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and
> -fdeprecate-binding options. These would take the (optionally qualified)
> name of a binding and control warnings tied to it. So if you invoked
> -fno-warn-binding "sillyFunction", then GHC would not warn you about the
> silliness of anything named sillyFunction. -fno-warn-binding
> "Data.Silly.sillyFunction" would limit the suppression to the silly
> function in Data.Silly. -fno-deprecate-binding would refrain from emitting
> deprecation warnings for the binding in question. -fno-deprecate-binding
> would presumably imply no-warn-binding, since someone who doesn't care that
> a function is going to be removed probably also doesn't care what else is
> wrong with it.
>
> 2. Named warning classes
>
> I'd like to add an optional "warning class" to the WARNING pragma,
> preceding the warning description. This would be a short string indicating
> what sort of warning is involved. This would be totally free-form, but the
> documentation would suggest a few conventional options such as "partial"
> and "slow". Then whole warning classes could be controlled with
> -fno-warn-class and -first-class.
> ___
> 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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Feature request bounty

[David Feuer]

I'd like to place a small bounty on
https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS .

If someone implements this request by GHC 8.2, I will buy them 24
bottles of high-end root beer (e.g., Maine Root) or something of
similar value agreeable to both parties. (*)

Thanks,
David Feuer

(*) Recipient responsible for customs/duty/taxes/shipping fees beyond US$10.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Grand Plan for 8.0.2

[Ben Gamari]

tl;dr: GHC 8.0.2 is coming, however there are a number of issues we
   would like to see resolved. Consequently it's not entirely clear
   when it will arrive, but if things go well it may be as early as
   this Friday.


Hello everyone,

Over the past few weeks I've been making preparations for the coming
8.0.2 release. I've merged a few more patches to the stable branch in
response to last week's call for merge requests, bringing the total up
to 180 commits since 8.0.1.

At this point there are only a couple things that remain to be cleared
up,

 * #12220, #12533: These are unfortunate behaviors of
   default signatures, #12220 being an interaction with type
   applications and #12533 being an obscure corner case. While we have a
   fix for these (d2958bd0), the fix changes the behavior of the
   typechecker's inaccessible code check, breaking some code on Hackage;
   this is documented as #12466. There are some tricky unresolved
   questions here regarding how we want the inaccessible code here to
   behave.

   At the moment I am leaning towards simply punting these off to 8.2.1.
   If you would like to see them fixed in 8.0.2, please say so.
   Moreover, please contribute your thoughts on #12466 as resolving the
   remaining questions on that ticket is a prerequisite for merging the
   fix for #12220.

 * #12954: Currently Haddock does not produce documentation for bundled
   pattern synonyms. There is a pull request [1] that may fix this but
   it is currently needing reviewers. It would be great to fix this for
   8.0.2, but ultimately someone is going to need to finish this up.

 * #10986: This is a rather unfortunate leak of temporary files which we
   would ideally fix since it can produce rather large temporary
   directories on the user's system.

 * #12519: Haddock inexplicably forgets to render the class members of
   Eq and Ord. It would be great if someone could get to the bottom of
   this.

 * #12433 is a rather nasty correctness bug which currently has no
   resolution.

 * #11819: There are still a number of full validation issues which
   would be nice to sort out.

I would like to be able to say that we have a concrete timeline for a
8.0.2 release and I was originally planning to propose a candidate
source release for late this week, however in light of the the large
number of unresolved issues, I think it would be unwise to commit to
this timeframe. I'll say that the candidate source tarball could come as
early as Friday, although sometime next week is far more likely.

As always, any help that you could offer on any of the above issues
would be greatly appreciated.

Cheers,

- Ben


[1] 
https://github.com/haskell/haddock/pull/494/commits/7984c8fb8f238793641a419c93fbcb4f6e933ae5


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

Restartable sequences

[Ben Gamari]

While I'll admit that I'm not terribly familiar with our STM
implementation, it came to mind while I was reading this article [1] on
the restartable sequences mechanism that might someday land in the Linux
kernel.

I thought you both might be interested.

Cheers,

- Ben


[1] http://lwn.net/Articles/697979/


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

Re: Custom warning suppression

[Richard Eisenberg]

Seems reasonable and useful to me. Is this a good use of the process here? 
https://github.com/ghc-proposals/ghc-proposals

> On Sep 7, 2016, at 10:39 AM, David Feuer  wrote:
> 
> Currently, the only way to suppress custom warnings and deprecations is with 
> -fno-warn-warnings-deprecations, which is a rather large hammer. I see two 
> ways we can improve this, and I propose that we should do both.
> 
> 1. Per-binding suppression
> 
> Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and 
> -fdeprecate-binding options. These would take the (optionally qualified) name 
> of a binding and control warnings tied to it. So if you invoked 
> -fno-warn-binding "sillyFunction", then GHC would not warn you about the 
> silliness of anything named sillyFunction. -fno-warn-binding 
> "Data.Silly.sillyFunction" would limit the suppression to the silly function 
> in Data.Silly. -fno-deprecate-binding would refrain from emitting deprecation 
> warnings for the binding in question. -fno-deprecate-binding would presumably 
> imply no-warn-binding, since someone who doesn't care that a function is 
> going to be removed probably also doesn't care what else is wrong with it.
> 
> 2. Named warning classes
> 
> I'd like to add an optional "warning class" to the WARNING pragma, preceding 
> the warning description. This would be a short string indicating what sort of 
> warning is involved. This would be totally free-form, but the documentation 
> would suggest a few conventional options such as "partial" and "slow". Then 
> whole warning classes could be controlled with -fno-warn-class and 
> -first-class.
> 
> ___
> 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

Custom warning suppression

[David Feuer]

Currently, the only way to suppress custom warnings and deprecations is
with -fno-warn-warnings-deprecations, which is a rather large hammer. I see
two ways we can improve this, and I propose that we should do both.

1. Per-binding suppression

Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and
-fdeprecate-binding options. These would take the (optionally qualified)
name of a binding and control warnings tied to it. So if you invoked
-fno-warn-binding "sillyFunction", then GHC would not warn you about the
silliness of anything named sillyFunction. -fno-warn-binding
"Data.Silly.sillyFunction" would limit the suppression to the silly
function in Data.Silly. -fno-deprecate-binding would refrain from emitting
deprecation warnings for the binding in question. -fno-deprecate-binding
would presumably imply no-warn-binding, since someone who doesn't care that
a function is going to be removed probably also doesn't care what else is
wrong with it.

2. Named warning classes

I'd like to add an optional "warning class" to the WARNING pragma,
preceding the warning description. This would be a short string indicating
what sort of warning is involved. This would be totally free-form, but the
documentation would suggest a few conventional options such as "partial"
and "slow". Then whole warning classes could be controlled with
-fno-warn-class and -first-class.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs