Simon Marlow writes:
> What pragma syntax should other Haskell compilers use? I don't think it's
> fair for GHC to have exclusive rights to the pragma syntax form the report,
> and other compilers should not be relegated to using {-# X-FOOHC ... #-}.
> But now we have all the same issues again.
>
What pragma syntax should other Haskell compilers use? I don't think it's
fair for GHC to have exclusive rights to the pragma syntax form the report,
and other compilers should not be relegated to using {-# X-FOOHC ... #-}.
But now we have all the same issues again.
Cheers
Simon
On Thu, 25 Oct 20
Niklas Larsson writes:
> Hi!
>
> Why not follow the standard in that pragmas were intended for all
> tools consuming Haskell ...
That much isn't clear to me. The Report defines the syntax very
specifically to be for "compiler pragmas" to be used by "compiler
implementations". I personally consid
Hi!
Why not follow the standard in that pragmas were intended for all tools
consuming Haskell and not for GHCs exclusive use? All that would require is to
make the warning opt-in.
Making other tools use a new syntax for the same functionality seems suboptimal
to me.
Regards,
Niklas
> 24 ok
It might be nice if GHC were to actually parse the extensible tool pragmas and
insert them into the AST!
Aesthetically, I prefer the {-# X_HLINT ... #-} syntax over the {-# TOOL HLINT
... #-} syntax, but I don't feel strongly about it.
On Wed, Oct 24, 2018, at 13:38, Ben Gamari wrote:
> Neil Mi
Neil Mitchell writes:
>> I'm trying to view the pragma question from the perspective of setting a
>> precedent for other tools. If a dozen Haskell tools were to approach us
>> tomorrow and ask for similar treatment to HLint it's clear that
>> hardcoding pragma lists in the lexer would be unsustai
> I'm trying to view the pragma question from the perspective of setting a
> precedent for other tools. If a dozen Haskell tools were to approach us
> tomorrow and ask for similar treatment to HLint it's clear that
> hardcoding pragma lists in the lexer would be unsustainable.
Why? Making the list
I think it makes a lot of sense to have a standard way for third-parties
to attach string-y information to Haskell source constructs. While it's
not strictly speaking necessary to standardize the syntax, doing
so minimizes the chance that tools overlap and hopefully reduc
> On Oct 17, 2018, at 10:22 AM, Simon Marlow wrote:
>
> but then nothing wil notice if you say {-# TOOL HLNIT ... #-} by mistak
This seems fixable. Any tool can slurp in all `TOOL` (or `X-`, which I prefer)
pragmas and look for ones that appear to be misspellings. Of course, this
doesn't st
> And sacrifice checking for misspelled pragma names in those namespaces? Sure
> we can say {-# TOOL FOO .. #-} is ignored by GHC, but then nothing wil notice
> if you say {-# TOOL HLNIT ... #-} by mistake.
Yes! But we can't have the whitelist of pragmas hardcoded in GHC, as
there may be arbitr
On Wed, 17 Oct 2018 at 15:02, Ben Gamari wrote:
> Simon Marlow writes:
>
> > Simon - GHC provides some protection against mistyped pragma names, in
> the
> > form of the -Wunrecognised-pragmas warning, but only for {-# ... #-}
> > pragmas. If tools decide to use their own pragma syntax, they don
Neil Mitchell writes:
> People expect pragmas that are machine readable to use the pragma
> syntax, and the Haskell report suggests that is the right thing to
> expect. They can be highlighted intelligently by IDEs, are immune from
> accidental mix ups with normal comments etc. The fact that prag
Moritz Angermann writes:
> Does this need to be *this* hardcoded? Or could we just parse the pragma and
> compare it to a list of known pragmas to be parsed from a file (or settings
> value?).
>
To be clear, I don't think we want to start considering `settings` to be
a user configuration file.
Simon Marlow writes:
> Simon - GHC provides some protection against mistyped pragma names, in the
> form of the -Wunrecognised-pragmas warning, but only for {-# ... #-}
> pragmas. If tools decide to use their own pragma syntax, they don't benefit
> from this. That's one downside, in addition to t
gt;
> Cheers
> Simon
>
> On Tue, 16 Oct 2018 at 23:34, Simon Peyton Jones
> wrote:
> I’m still not understanding what’s wrong with
>
>
>
> {- HLINT blah blah -}
>
>
>
> GHC will ignore it. HLint can look at it. Simple.
>
>
>
>
wrong with
>
>
>
> {- HLINT blah blah -}
>
>
>
> GHC will ignore it. HLint can look at it. Simple.
>
>
>
> I must be missing something obvious.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Simon
> Marlow
> *Sent:* 1
23:39
> To: Simon Peyton Jones
> Cc: Simon Marlow ; Neil Mitchell ;
> ghc-devs@haskell.org Devs
> Subject: Re: Treatment of unknown pragmas
>
>
>
> One problem is you have to release a new ghc every time someone comes up with
> a new pragma-using tool that starts to c
}.
> Why would I need to produce a new GHC if someone wants to us {- WIMWAM
> blah -}?
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery
> *Sent:* 16 October 2018 23:39
> *To:* Simon Peyton Jones
> *Cc:* Simon Marlow ; Neil Mitchell <
> ndmitch...@gmail.com>;
o us {- WIMWAM blah -}?
>
> Simon
>
> From: Brandon Allbery
> Sent: 16 October 2018 23:39
> To: Simon Peyton Jones
> Cc: Simon Marlow ; Neil Mitchell ;
> ghc-devs@haskell.org Devs
> Subject: Re: Treatment of unknown pragmas
>
> One problem is you have to rele
Subject: Re: Treatment of unknown pragmas
One problem is you have to release a new ghc every time someone comes up with a
new pragma-using tool that starts to catch on. Another is that the more of
these you have, the more likely a typo will inadvertently match some tool you
don't even know
vious.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Simon
> Marlow
> *Sent:* 16 October 2018 21:44
> *To:* Neil Mitchell
> *Cc:* ghc-devs
> *Subject:* Re: Treatment of unknown pragmas
>
>
>
> I suggested to Neil that he add the {-# HLINT #
I’m still not understanding what’s wrong with
{- HLINT blah blah -}
GHC will ignore it. HLint can look at it. Simple.
I must be missing something obvious.
Simon
From: ghc-devs On Behalf Of Simon Marlow
Sent: 16 October 2018 21:44
To: Neil Mitchell
Cc: ghc-devs
Subject: Re: Treatment of
Another option could be to introduce a lighter ANN that doesn’t actually embed
anything into the module, instead just making the annotations available to
plugins and API users during compilation of that particular module. It could
also be restricted to string annotations to avoid invoking the ty
Ben Gamari writes:
> Brandon Allbery writes:
>
>> The problem with ANN is it's part of the plugins API, and as such does
>> things like compiling the expression into the program in case a plugin
>> generates code using its value, plus things like recompilation
>> checking end up assuming plugins
Brandon Allbery writes:
> The problem with ANN is it's part of the plugins API, and as such does
> things like compiling the expression into the program in case a plugin
> generates code using its value, plus things like recompilation
> checking end up assuming plugins are in use and doing extra
Eric Seidel writes:
> On Tue, Oct 16, 2018, at 15:14, Ben Gamari wrote:
>
>> For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`
>
> LiquidHaskell does not use `{-@ LIQUID ... @-}`, we just write the
> annotation inside `{-@ ... @-}` :)
>
Ahh, I see. I saw [1] and assume
Maybe the right answer is to ignore unknown OPTIONS_* pragmas and then use
OPTIONS_HLINT?
On Tue, Oct 16, 2018 at 4:44 PM Simon Marlow wrote:
> I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed
> like the least worst option taking into account the various issues that
> h
I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed
like the least worst option taking into account the various issues that
have already been described in this thread. I'm OK with adding HLINT; after
all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other
OPTIO
The problem with ANN is it's part of the plugins API, and as such does
things like compiling the expression into the program in case a plugin
generates code using its value, plus things like recompilation checking end
up assuming plugins are in use and doing extra checking. Using it as a
compile-ti
> > This sounds exactly like the existing ANN pragma, which is what I've wanted
> > LiquidHaskell to move towards for a long time. What is wrong with using the
> > ANN pragma?
>
> Significant compilation performance penalty and extra recompilation.
> ANN pragmas is what HLint currently uses.
Th
> > I'm a bit skeptical of this idea. Afterall, adding cases to the
> > lexer for every tool that wants a pragma seems quite unsustainable.
>
> I don't find this argument that convincing. Given the list already
> includes CATCH and DERIVE, the bar can't have been _that_ high to
> entry. And yet, t
> A warning flag is an interesting way to deal with the issue. On the
> other hand, it's not great from an ergonomic perspective; afterall, this
> would mean that all users of HLint (and any other tool requiring special
Yep, this means every HLint user has to do an extra thing. I (the
HLint author
On Tue, Oct 16, 2018, at 15:14, Ben Gamari wrote:
> For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`
LiquidHaskell does not use `{-@ LIQUID ... @-}`, we just write the annotation
inside `{-@ ... @-}` :)
> I think it makes a lot of sense to have a standard way for th
Vladislav Zavialov writes:
> What about introducing -fno-warn-pragma=XXX? People who use HLint will
> add -fno-warn-pragma=HLINT to their build configuration.
>
A warning flag is an interesting way to deal with the issue. On the
other hand, it's not great from an ergonomic perspective; afterall,
I like the suggestion of a flag. For any realistic compilation you
have to pass a large number of flags to GHC anyway. `stack`, `cabal`
or so on can choose to pass the additional flag by default if they
wish or make it more ergonomic to do so.
On Tue, Oct 16, 2018 at 7:58 PM Jared Weakly wrote:
>
The main problem I see with this is now N tools need to implement support
for that flag and it will need to be configured for every tool separately.
If we standardize on a tool pragma in the compiler, all that stays
automatic as it is now (a huge plus for tooling, which should as beginner
friendly
I rather agree.
We don't even need a convention do we? /Any/ comment in {- -} is ignored
by GHC /except/ {-# ... #-}. So tool users are free to pick whatever
convention they like to identify the stuff for their tool.
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Ben Gamari
What about introducing -fno-warn-pragma=XXX? People who use HLint will add
-fno-warn-pragma=HLINT to their build configuration.
On Tue, Oct 16, 2018, 20:51 Ben Gamari wrote:
> Hi everyone,
>
> Recently Neil Mitchell opened a pull request [1] proposing a single-line
> change: Adding `{-# HLINT ..
38 matches
Mail list logo
