| My only worry is around the just implemented TH additions regarding | annotations. I don't clearly see what would happen if: | - a TH library exports a function that generates annotations when | spliced. | - and the user uses this function in a .hs file, | - without specifying the language extension. But this is true for ANY language extension. If a TH library exports a function that generates (say) a type family declaration, and you splice that into a file, do you need -XTypeFamilies in the client file? I think currently you do. So your point is a good one but it's orthogonal. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Gergely Risko | Sent: 06 November 2013 11:57 | To: ghc-devs@haskell.org | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Annotations | | On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones | writes: | | > I’m inclined to add a language extension “Annotations”. | > | > · Without it {-# ANN … #-} pragmas are ignored as comments | > | > · With it, they are treated as annotations | > | > Do you agree? | | I generally agree that this should be a language extension. | | My only worry is around the just implemented TH additions regarding | annotations. I don't clearly see what would happen if: | - a TH library exports a function that generates annotations when | spliced. | - and the user uses this function in a .hs file, | - without specifying the language extension. | | I'd it to work even in that case. | | I guess the behavior in this corner case depends heavily on how this is | actually implemented. If e.g. the reader is the only component that | checks if the language extension is turned on, then I imagine that the | TH way of putting in the annotation into the AST would just work. | | On the other hand if the reader recognizes the annotations either way | and some component after TH splicing is checking for the language | extension, then my use-case would blow up. | | TH currently is lenient in cases like this. E.g. if you know that a | Name is exported from a module and you reference it directly, without | importing it everything will just work. I'd like to have the same | behavior for annotations. | | Thanks, | Gergely | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Currently, in all the cases I can think of if the splice generates something that uses an extension then the module must have that flag turned on. Sent from my iPhone

On Nov 6, 2013, at 6:57 AM, Gergely Risko wrote:

On Wed, 6 Nov 2013 10:55:09 +0000, Simon Peyton-Jones writes:

...

I’m inclined to add a language extension “Annotations”.

· Without it {-# ANN … #-} pragmas are ignored as comments

· With it, they are treated as annotations

Do you agree?

I generally agree that this should be a language extension.

My only worry is around the just implemented TH additions regarding annotations. I don't clearly see what would happen if: - a TH library exports a function that generates annotations when spliced. - and the user uses this function in a .hs file, - without specifying the language extension.

I'd it to work even in that case.

I guess the behavior in this corner case depends heavily on how this is actually implemented. If e.g. the reader is the only component that checks if the language extension is turned on, then I imagine that the TH way of putting in the annotation into the AST would just work.

On the other hand if the reader recognizes the annotations either way and some component after TH splicing is checking for the language extension, then my use-case would blow up.

TH currently is lenient in cases like this. E.g. if you know that a Name is exported from a module and you reference it directly, without importing it everything will just work. I'd like to have the same behavior for annotations.

Thanks, Gergely

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs