> I don't have a solution and I hate bike-shedding. I just made this
> message to make sure the fact had been considered before release.
Yes, I bumped into this issue quite early. After some discussion it was decided
that this
potential ambiguity is an acceptable trade-off.
Janek
Dnia niedziela
This approach wouldn't quite work.
- It seems to kick in only when instantiating a Levity variable. That would not
happen when using :info.
- It is possible to have unlifted types about even without -XMagicHash.
-XMagicHash is simply a lexer extension, nothing more. By convention, we use
the #
On Feb 14, 2016, at 1:51 PM, Sven Panne wrote:
>
> IMHO, the distinction between "during development" and "outside of it" is
> purely hypothetical.
I find this comment quite interesting, as I see quite a large difference
between these.* For example, I use -Werror during development, but not
There is currently an interesting discussion on Reddit on GHC compile times
https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/
I feel that this is a serious problem; so, it probably ought to be discussed
here as well.
Manuel
_
Just as one data point, the Swift compiler is by default showing warnings about
upcoming changes. Just like deprecation warnings, I do find that helpful. Based
on that experience, including -Wcompat in -Wall seems like a good plan to me.
Manuel
> Ben Gamari :
>
> tl;dr. GHC has a new set of wa
When this was first discussed a bunch of alternatives were tossed around,
mostly involving new keywords, or putting a conditional result keyword in
place. Here you can pick the name of the result type, so it doesn't pick
any naming conventions for you.
My understanding is that the current syntax w
2016-02-14 17:12 GMT+01:00 Ben Gamari :
> [...] This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's war
tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
advance notice of coming library changes. We want to know whether
you think this set should be included in -Wall. See the Wiki [4]
and voice your opinion via the linked poll.
Hello everyone,
GHC 8.0.1 wil
I guess my point is that the most natural parsing of
class Hcl a b where
type Ht a b = r | r -> a b
is (type Ht a b = r) (| r -> a b) rather than (type Ht a b) (= r | r -> a b).
A concrete example, in the case of functional dependencies, the
vertical bar is used to signal what we expect *a
> 2. Without the infectivity annotation, this declares an associate type
> synonym default. This isn't valid because Ht is not declared as an
> associated type before hand and r is not mentioned on the LHS.
>
> class Hcl a b where
> type Ht a b = r
Indeed, this is invalid and GHC rejects this,
10 matches
Mail list logo
