Re: Proposal: EPHEMERAL pragma

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