The question of whether the warnings should come by default or not is a question of how serious the programmer is when they declare a type as EPHEMERAL. In Pedro's use cases, I would be very serious about it — as Ryan said, performance tends to "tank" otherwise. ### Proposal Extensions I think a more granular pragma targeting value declarations would also be nice.

{-# EPHEMERAL T #-} x = …

This would tell GHC that I really don't want any values of type T in x's core. It might also make sense to have a EPHEMERAL pragma that has a module as it's scope. A related and more expressive pragma might be something like:

{-# USES foo 1, bar 2 #-} x = …

This hypothetical pragma would similarly a) guide GHC's inliner and b) emit warnings if the programmer's declared expectations (eg that foo occurs once and bar occurs twice) are not met by x's ultimate RHS in Core. Of course, the cost of the USES pragma's expressiveness is that it may lead to "brittle" source code. However, if performance is important enough to be part of your code's specification, then this may generate legitimate warnings (perhaps even errors, with a sub-pragma!) — especially in rather mature performance-focused packages. On Thu, Oct 25, 2012 at 10:00 AM, Axel Simon wrote:

On 25.10.2012, at 16:45, Johan Tibell wrote:

...

Interesting idea.

On Thu, Oct 25, 2012 at 6:56 AM, José Pedro Magalhães wrote:

...

3. Emit a warning if the generated core code still contains uses of Rep.

I think this part will be really annoying, as GHC might end up generating warnings that the programmer can do nothing about (because some optimization failed to remove Rep).

I think this is exactly the right idea. A compiler should emit errors about bad typing since type inference is somewhat complete, but should emit warnings about other incomplete analyses or optimizations.

If you think that this is too noisy, by all means, don't emit these warnings by default and add a flag that enables them.

my 2p, Axel

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Are you restricting Rep to non-recursive uses? Or has GHC's inliner finally learned how to behave well in the presence of recursion? If anyone could explain (in precise terms) what it means to “behave well in the presence of recursion” then there’s a chance that it might. But up to now, no, it hasn’t I’m afraid. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Jan-Willem Maessen Sent: 25 October 2012 20:19 To: José Pedro Magalhães Cc: GHC users Subject: Re: Proposal: EPHEMERAL pragma On Thu, Oct 25, 2012 at 9:56 AM, José Pedro Magalhães mailto:jpm@cs.uu.nl> wrote: Hi all, Following up on a chat with Simon Peyton Jones at ICFP, I would like to discuss the possible introduction of a EPHEMERAL pragma. For example: {-# EPHEMERAL Rep #-} data Rep = ... This pragma would indicate that the programmer intends the Rep datatype not to be present in the final generated core code. Its proposed semantics are the following: 1. Make the compiler very keen to inline any functions that produce or consume Rep. 2. If Rep is exported, make all functions that operate on Rep INLINABLE (that is, make their code available for inlining in other modules). 3. Emit a warning if the generated core code still contains uses of Rep. Are you restricting Rep to non-recursive uses? Or has GHC's inliner finally learned how to behave well in the presence of recursion? -Jan-Willem Maessen