We get people bitching on both sides, so let's just do it. PR's welcome imo.
This looks sufficient to me, but I would like an explanation for the test changes from someone before proceeding. @bgamari any ideas here?
Wouldn't elem
being implemented explicitly for types where's problematic to define via elem <foo> . toList
be the solution here? It sounds less like we need a warning, and more to run through the various implementations and sort out the problematic default behaviors.
@bgamari is this a core libraries issue? Seems like a GHC-specific issue unless SrcLoc
is defined specifically in base
.
Adding to the mix (due to Ed's parsnip
package):
newtype Maybe# a = Maybe# (# a | (##) #)
pattern Just# :: a -> Maybe# a
pattern Just# a = Maybe# (# a | #)
pattern Nothing# :: Maybe# a
pattern Nothing# = Maybe# (# | (##) #)
{-# complete Just#, Nothing# #-}
Emily Pillmore (e8d962ac) at 17 Sep 20:16
Emily Pillmore (e8d962ac) at 17 Sep 20:11
Add language fixes per issue #237
Emily Pillmore (4a73fb93) at 17 Sep 20:09
Add language fixes per issue #237
See #237
Emily Pillmore (64db5268) at 17 Sep 20:07
Add language fixes per issue #237
LGTM thanks @treeowl and all who reviewed
Yes, a thousand times.
@mpickering do you mind merging?
I've given my $0.02 in the libraries thread:
Regarding
HasCallStack
vs Partial, well, we haveHasCallStack
now, and we can havePartial
later - these changes are not zero-sum. However, I do not want to see clear benefits die in favor of what amounts to a bikeshed until the proposal is as fleshed out as this one. I say HasCallStack is the right choice now, if Partial is the right choice later.
Let's get this in. I'm +1. @core-libraries
Re: procedure.
I agree with @sgraf812 and @carter - this is probably best served as a Libraries request (though, don't forget to show that you've already raised a MR with a POC for discussion!).
Re: the idea
It's hard to tell whether this is a good idea or not. I'm very neutral on the concept of syntax for Map
-ey entries like ->
and :=
. When I was writing Scala full time, ->
was maligned as a concept due to it not being entirely clear why it existed when (,)
did just fine. You end up typing 1 more character (spaces on either side of the operator) than (,)
, and you receive "better" syntax in return. Additionally, ->
was ambiguous as far as syntax goes, and non-obvious that it was a tupling mechanism. :=
is better in my opinion, so I'm positive on the choice of syntax, but still neutral on the utility of the thing.
From a pragmatist standpoint, I was just going to suggest the use of Word64
. Code-wise, it's nearly costless, and the upper bound is more than enough for any delay one could think of: 18446744073709551615µs is close 6 millennia-worth of delay bandwidth.
However, the amount of code breakage would be undesirable. I'm leaning towards the idea of genericThreadDelay
taking an Integral
on this one, unless we can confirm that the code breakage isn't too bad for threadDelay
so we can justify Word64
.
@chessai @andrewthad What do you think?