On Mon, 15 Oct 2018 at 07:17, Ben Gamari wrote:
> The GHC team is pleased to announce the availability of GHC 8.4.4
Thank you
> As always, the full release notes can be found in the users guide,
https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/8.4.4-notes.html#base-library
I
Yeh, I'd missed it was a normal comment and not a new pragma.
Pretty much every solution has some screw case; sometimes you get to choose
between a bunch of "simple, elegant, and wrong" options and have to decide
which "and wrong" will be least expensive (or least frustrating). And a
problem with
I think Brandon may have misread your example as "{-# HLINT ... #-}".
One problem with "{- HLINT" (although I'm personally not in favor of the
special-casing) is that if it's just a Haskell comment then it itself is
vulnerable to typos. E.g. if I type "{- HILNT foo -}" (L and I swapped), hlint
The SSE types require 16-byte alignment. Most of the original SSE
instructions have versions that accept non-aligned data though.
Alexander
On Tue, Oct 16, 2018 at 11:18 PM Simon Marlow wrote:
> I vaguely recall that this was because 16 byte alignment is the minimum
> you need for certain
I’m still not getting it. GHC ignores everything between {- and -}. 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 ;
ghc-devs@haskell.org Devs
Mathieu
Things (especially major things) for a release should land in master before the
cut-off date. But there is quite a way to go before linear types land in
master… When Arnaud is ready to submit a diff, I (and, I earnestly hope,
other) can begin a code review – but so far I have not
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 about but ghc does.
On Tue, Oct 16, 2018 at 6:34
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
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
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
I vaguely recall that this was because 16 byte alignment is the minimum you
need for certain foreign types, and it's what malloc() does. Perhaps check
the FFI spec and the guarantees that mallocForeignPtrBytes and friends
provide?
Cheers
Simon
On Thu, 11 Oct 2018 at 18:44, Ömer Sinan Ağacan
I personally love to hack things up with parser combinators, but for
anything longer term where I want a degree of confidence that changes
aren't going to introduce new problems I'd still use Happy. Yes it's a
total pain sometimes, and LALR(1) is very restrictive, but I wouldn't want
to lose the
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
>
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
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
> > 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.
> > 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,
> 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
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
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
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
Hi everyone,
Recently Neil Mitchell opened a pull request [1] proposing a single-line
change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
lexer for every tool that wants a pragma seems quite unsustainable.
Thanks Alp and Ben!
I fully agree with you. Let's go ahead.
Ben: I guess you'll do the actual merge -- feel free to do this whenever you
like.
> How should we handle ticket tracking post-merge? The easiest option
> would probably be to keep the existing tickets on GitHub and ask that
> new
Hi Ben,
just a heads up: we are still on track for a Diff submission for linear
types by end of October (the cut-off date you advertized at the top of this
thread for feature work on GHC 8.8, and the one we stated we'd aim for in
September). We might run into last minute blockers of course, but
28 matches
Mail list logo
