Digging around online, I suspect that you may not have the GNU C++ compiler
installed at all. Take this with a shaker of salt.
David FeuerWell-Typed, LLP
Original message From: Simon Peyton Jones via ghc-devs
Date: 11/20/17 8:14 AM (GMT-05:00) To:
ghc-devs@haskell.org Subje
I don't know anything myself, but if you're doing anything remotely related to
Haskell and macro systems, you should probably read up on what Alexis King (AKA
lexi-lambda) has been up to lately, and maybe get in touch with her.
David FeuerWell-Typed, LLP
Original message From:
Sometimes it woulld be useful to be able to reason backwards about type
families.
For example, we have
type family a && b where
'False && b = 'False
'True && b = b
a && 'False = 'False
a && 'True = a
a && a = a
If we know something about either of the ar
reasonable way forward?
David Feuer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
The :sprint, :print, and :force commands in GHCi fall into infinite
loops when confronted by cyclical data. This bit me hard in
https://phabricator.haskell.org/D4085 because that produces cyclical
TypeReps, which is trouble for (e.g.) the test break011 which tries to
:force a SomeException (which w
Sorry; wasn't thinking straight!
David FeuerWell-Typed, LLP
Original message From: "Boespflug, Mathieu"
Date: 9/28/17 3:56 AM (GMT-05:00) To: David Feuer Cc:
ghc-devs Subject: Re: Including libffi as a submodule
Aren't we talking about the C
On Tuesday, September 26, 2017 9:38:11 PM EDT Ben Gamari wrote:
> Numerous attempts have
> been made to get the libffi maintainers to cut a new release but sadly
> no progress has been made in over six months of trying.
Has anyone followed the process described in the somewhat poorly named
https:
the
generalization I describe, so I wanted to check first how much that matters.
David FeuerWell-Typed, LLP
Original message From: Richard Eisenberg
Date: 9/25/17 2:42 PM (GMT-05:00) To: David Feuer
Cc: Ben Gamari ,
ghc-devs@haskell.org Subject: Re: Why isn't this Typ
nstantiated at some monotype for `a`.
>
> So I think that this boils down to impredicativity and that the
> implementation is doing the right thing here.
>
> Richard
>
> > On Sep 24, 2017, at 5:45 AM, David Feuer wrote:
> >
> > data Foo :: (forall a. a ->
I think changes to the RTS, code generator, and general heap layout are exactly
where we *do* want to worry about these very low-level details. Changes in type
checking, desugaring, core-to-core, etc., probably are not, because it's just
too hard to tease out the relationship between what they d
I don't see why Typeable (Foo 'Just) requires that. I'd expect to get back a
TrTyCon, not a TrApp. Some modifications to the structure of TrTyCon might be
required.
David FeuerWell-Typed, LLP
Original message From: Ryan Scott
Date: 9/24/17 10:08 AM (GMT-05:00) To: ghc-devs@
data Foo :: (forall a. a -> Maybe a) -> Type
Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to
excluding Foo proper, because it can't be decomposed with Fun. But why not Foo
'Just? Is there a fundamental reason, or is that largely an implementation
artifact?
David Feuer
Could you maybe point me toward where the constant folding is happening in this
context? I'd like to take a glance and see if I can guess how to upgrade it to
deal with what we know things *aren't*. Thanks in advance.
David FeuerWell-Typed, LLP___
ghc
Ah, nice. I was actually exploring the vague general idea behind that approach
earlier this evening. Magalhães (unsurprisingly) has developed it much much
further.
David FeuerWell-Typed, LLP
Original message From: Ryan Scott
Date: 9/2/17 10:36 PM (GMT-05:00) To: ghc-devs@ha
s considerably more
useful. Unfortunately, while I'm pretty sure those are completely legit for
any Generic-derived types, I don't think there's ever any way to prove
them in Haskell! Ugh.
On Thursday, August 31, 2017 3:37:15 PM EDT David Feuer wrote:
> I've been thinking for
I've been thinking for several weeks that it might be useful to offer
type-level generics. That is, along with
to :: Rep a k -> a
from :: a -> Rep a
perhaps we should also derive
type family To (r :: Rep a x) :: a
type family From (v :: a) :: Rep a x
This would allow us to use generic programmi
Gdfo%3D&reserved=0
|
| >---
|
| commit a055f240aeda538c656a59e810870e6a2ccc2db7
| Author: David Feuer
| Date: Mon Aug 28 14:35:19 2017 -0400
|
| Adjust test suite stats
|
| T1969 and T12150 we
Atomic operations, or the lack thereof, don't seem terribly relevant to
immutable Haskell constructor fields.
David FeuerWell-Typed, LLP
Original message From: Carter Schonwald
Date: 8/26/17 10:56 PM (GMT-05:00) To: Florian
Weimer , Michal Terepeta Cc:
ghc-devs Subject:
Once in a while, one desires to tie a recursive knot and is stymied by a
strict data constructor. I recently encountered this problem trying to
improve the implementation of `never` in the `streaming` package.
The Stream type is defined thus:
data Stream f m r = Step !(f (Stream f m r))
dataToTag# is documented as getting the tag number of an enumeration,
which is perfectly reasonable because it's designed to support deriving Enum.
But it *appears* to work also for non-enumeration datatypes:
dataToTag# Nothing = 0#
dataToTag# (Just 3) = 1#
Does this actually always work? If so,
On Tuesday, July 18, 2017 3:55:28 PM EDT Conal Elliott wrote:
> Hi Sebastian,
>
> Thanks for the reply. It's that I don't want `exampleC` to be eta-expanded.
> Apparently GHC does by default even when doing so moves computation under
> lambda. I've thought otherwise for a very long time.
GHC real
On Sunday, July 9, 2017 1:05:44 AM EDT Andrés Sicard-Ramírez wrote:
> While testing this RC candidate on Agda we found a compilation error.
>
> The error was caused by an *unused* module which *is* compiled by this
> RC but it *is not* compiled by previous versions of GHC including
> 8.2.1 RC 2. T
There are (at least) two situations that I don't think we currently have a good
way to track:
1. A new bug has been verified, but we do not yet have an expect_broken test
case.
2. A bug has been fixed, but we are waiting for a test case.
Lacking (1) means that we have to manually dig through th
Edward Kmett has explained that this isn't sufficient when things go higher
order. His suggested improvement is
liftCoercion :: Maybe (Coercion a b -> Coercion (f a) (f b))
David FeuerWell-Typed, LLP
Original message From: Ryan Scott
Date: 6/6/17 1:41 PM (GMT-05:00) To:
On Friday, May 26, 2017 9:03:15 AM EDT Simon Peyton Jones wrote:
> 1. Which is better to start with: HsSyn or Core? Intuition suggests this sort
> of thing could be very helpful for making zapping more reliable and ensuring
> its efficiency, but there may be better reasons to start with HsSyn.
>
I haven't looked in detail yet, but there seem to be good ideas. I have two
questions:
1. Which is better to start with: HsSyn or Core? Intuition suggests this sort
of thing could be very helpful for making zapping more reliable and ensuring
its efficiency, but there may be better reasons to sta
Be aware that some of the biggest performance problems with TH simply can't be
fixed without changes to the TH language. For details, see Edward Yang's blog
post:
http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/
There was a Reddit thread discussing that post
, LLP
Original message From: George Colpitts
Date: 4/6/17 9:39 AM (GMT-05:00) To: David Feuer
, Jens Petersen , Ben Gamari
Cc: GHC developers Subject: Re:
testsuite not in GHC 8.2.1-rc1 source tarball ?
Thanks Brandon
After downloading the source tarball and doing a
I'm not sure why you're trying to run things from the libffi directory. As far
as I know, the test suite is normally run from ghc/testsuite.
David FeuerWell-Typed, LLP
Original message From: George Colpitts
Date: 4/5/17 9:17 PM (GMT-05:00) To: Jens
Petersen , Ben Gamari Cc
nsistent to treat tuples as transparent and consider every component with
> type `a`, or is it more consistent to treat tuples as opaque and reuse the
> existing Foldable instance for tuples even if it might cause a compile time
> error?
>
>
> On Tue, Mar 21, 2017, 4:34 PM David Feuer
This seems much too weird:
*> :set -XDeriveFoldable
*> data Foo a = Foo ((a,a),a) deriving Foldable
*> length ((1,1),1)
1
*> length $ Foo ((1,1),1)
3
I've opened Trac #13465 [*] for this. As I write there, I think the
right thing is to refuse to derive Foldable for a type whose Foldable
instance
Thinking more about this I/O demand analysis thing. I don't think it's possible
for the compiler to decide for itself what to fuzz, but a user might know very
well. Given
m >>= f
there are really two sensible approaches:
1. Want to ensure m is executed even if the action produced by f will diverg
Actually, I just had a thought. What if we ran ST computations with a different
state token type? Say, State# FakeWorld? Would that let them escape the hack?
David FeuerWell-Typed, LLP
Original message From: David Feuer
Date: 3/15/17 6:38 AM (GMT-05:00) To: GHC developers
I don't see how we can take advantage of this, but IO and ST seem quite
different from a strictness analysis perspective. The whole I/O hack is
completely unnecessary for ST. Ugh.
David FeuerWell-Typed, LLP___
ghc-devs mailing list
ghc-devs@haskell.org
Kill it! That's terrible practice indeed. Speaking of generated files, it's
time to check if our Unicode tables are up to date.
David FeuerWell-Typed, LLP
Original message From: Ben Gamari Date:
3/13/17 6:57 PM (GMT-05:00) To: GHC developers
Subject: Removing core-spec.pdf
t that's only safe as long as the interleaved IO won't float out and get
performed before it's forced by normal IO.
But the unsafeInterleaveIO story seems much less important, in the grand
scheme of things, than making everything else run fast. If indeed it's
otherwise safe to mark th
/wiki/FixingExceptions
Thanks,
David Feuer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
I dug a little further into what you tried to do with catch and where I
think it went wrong. You can see my thoughts in the notes I added in D3263.
It could even be possible to fix the problem for real by changing the
DmdRes domain again. Originally, we broke it up into Diverges and Dunno.
You adde
On Wednesday, March 1, 2017 8:17:05 AM EST Simon Peyton Jones via ghc-devs
wrote:
> David
> Thanks for moving my early-inline patch series to HEAD.
> You'll remember that I pushed this patch (below) to spj-early-inline2
> Can you be sure to cherry-pick this one too? It's important and I don't see
I can't fix that (no windows) but I just broke all the builds with a -Werror
mistake and I can fix that one...
David FeuerWell-Typed, LLP
Original message From: Simon Peyton Jones via ghc-devs
Date: 2/28/17 7:07 PM (GMT-05:00) To:
ghc-devs@haskell.org Subject: Windows build
It's possible for code to throw an exception that itself throws an
imprecise exception. Such an exception is a bit tricky to catch. For
example:
import Control.Exception
strange = throwIO (undefined :: SomeException) `catch` \ex ->
case () of
_ | Just _ <- (fromException ex :: Maybe IOError
For good or ill, Simon doesn't want RULES for datacons. T12689 has to be
removed (leaving T12689a, which is still fine). But I don't know enough about
what you're doing with T12689broken to know how to make it express the right
idea after this change. Can you please advise?
Than
On Tuesday, February 21, 2017 2:09:04 PM EST David Feuer wrote:
> I've been working on trying to get the branch in shape for review and such,
> but I see that you're also still working on it. So we don't tread on each
> other's toes too much, I'm wondering if
ich you might change, etc.
Thanks,
David Feuer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Yes, we definely want these. Are you wanting each of these submitted as a
separate differential *in order*? Or do you want a more complex mix-and-match?
Also, are there any commits you think should be squashed?
On Friday, February 17, 2017 4:41:33 PM EST Simon Peyton Jones via ghc-devs
wrote:
>
> · GHC does not (knowingly) support it today
>
> · It is a deeply weird thing to do
>
> · If you want to do it, write you own “smart constructor” mkLCon1,
> that inlines when you say
> mkLCon1 x = LCon1 x
>
> {-# INILNE [0] mkLCon1 #-}
&
On Friday, February 17, 2017 12:33:12 AM EST Simon Peyton Jones via ghc-devs
wrote:
> The "L" rule becomes problematic when we try to identify static data the
> simplifier shouldn't have to try to optimize. If it identifies LCon 0 as
> static, the "L" rule will never fire.
> Why doesn’t it fire?
fire. We'd like to be able to phase
that inline to give it a chance.
The "L" rule becomes problematic when we try to identify static data the
simplifier shouldn't have to try to optimize. If it identifies LCon 0 as
static, the "L" rule will never fire.
On Feb
posed new scheme?
>
>
>
> I’m lost
>
>
>
> Simon
>
>
>
> *From:* David Feuer [mailto:david.fe...@gmail.com]
> *Sent:* 16 February 2017 23:51
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs ; Reid Barton ;
> Ben Gamari
> *Subject:* RE: Static data and RULES
are trying to
> solve? Why does the fast-path make it harder?
>
>
>
> Maybe open a ticket?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *David
> Feuer
> *Sent:* 16 February 2017 22:13
> *To:* Ben Gamari ; R
-devs@haskell.org Subject: Re: Static data and RULES
Hi,
Am Donnerstag, den 16.02.2017, 17:12 -0500 schrieb David Feuer:
> Strict constructor wrappers will all be allowed to inline after
> demand analysis and worker/wrapper. This matches the way we now
> handle wrappers actually created in
Ben Gamari and Reid Barton are interested in making it cheaper for static
data to pass through simplification. The basic idea is that if a term is
already made entirely of data constructors and literals, then there's
nothing left to optimize.
However, RULES are allowed to match on data constructor
We discussed trying to come up with a primitive
eagerlyBlackhole# :: a -> a
-- meaning
eagerlyBlackhole a = runRW# $ \s ->
case noDuplicate# s of _ -> a
that would guarantee that the thunk is entered by only one thread. There
are important situations where that check is redundant. Consider this
eve can use a few rewrite rules to reduce costs substantially in some
situations. I
will add those to the differential.
Original message ----
From: Simon Marlow
Date: 1/31/17 3:59 AM (GMT-05:00)
To: Simon Peyton Jones
Cc: David Feuer , ghc-devs@haskell.org
Subject: Re: Lazy ST
inlining.
>
> Unless I'm missing something.
>
> I think there's a ticket somewhere about extending SpecConstr to work on
> function arugments, but it's tricky to do.
>
> Simon
>
> | -Original Message-
> | From: David Feuer [mailto:da...@well-typed.c
On Monday, January 30, 2017 9:50:56 PM EST Simon Marlow wrote:
> Unfortunately the mechanisms we have right now to fix it aren't ideal -
> noDuplicate# is a bigger hammer than we need.
Do you think you could explain this a bit more? What aspect of nuDuplicate# is
overkill? What does it guard aga
st backed by use-cases where something good is not
> happening. Do you have some?
> Simon
>
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David
> Feuer
Sent: 27 January 2017 16:42
> To: ghc-devs
> Subject: Constant functions and selectors make for interesting
On Monday, January 30, 2017 1:50:29 PM EST Reid Barton wrote:
> I wrote a lazy ST microbenchmark (http://lpaste.net/351799) that uses
> nothing but lazy ST monad operations in the inner loop.
This benchmark doesn't really look like code I'd expect people to use in
practice. Normally, they're usin
I forgot to CC ghc-devs the first time, so here's another copy.
I was working on #11760 this weekend, which has to do with concurrency
breaking lazy ST. I came up with what I thought was a pretty decent solution (
https://phabricator.haskell.org/D3038 ). Simon Peyton Jones, however, is quite
un
GHC's inliner has a notion of "interesting argument" it uses to encourage
inlining of functions called with (I think) dictionary arguments. I think
another class of argument is very interesting, by being very boring. Any
argument that looks like either
\ _ ... (Con _ ... x ... _ ) ... _ -> coerce
what
(if anything) is known about the relationships between the source spans in the
the argument to the nubBy. This code is proving to be a bit of a hot spot in
#11095 and the better we understand what's going on the better our chances of
coming up with good solutions.
Thanks,
David
Date: 1/23/17 4:47 PM (GMT-05:00) To: David Feuer
Cc: ghc-devs@haskell.org Subject: RE: Floating lazy
primops
We should have this conversation on a ticket, perhaps #13027.
| good at the time). Are there actually any primops with lifted arguments
| where we *want* speculation? Perhaps the most
I've updated https://ghc.haskell.org/trac/ghc/wiki/MagicalReflectionSupport to
reflect both Simon's thoughts on the matter and my own reactions to them. I
hope you'll give it a peek.
David Feuer
___
ghc-devs mailing list
ghc-devs@h
that entails.
On Wednesday, January 18, 2017 2:45:04 PM EST David Feuer wrote:
> I opened up https://phabricator.haskell.org/D2987 to mark
> reallyUnsafePtrEquality# can_fail, but in the process I realized a couple
> things.
>
> 1. Part of https://phabricator.haskell.org/rGHC5a9a17380
being applied to an unevaluated argument? If not, perhaps the CorePrep
specials can be removed altogether.
David Feuer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
>> David says that this paper is relevant
>>
>> http://okmij.org/ftp/Haskell/tr-15-04.pdf
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* David Feuer [mailto:david.fe
fiable t where
type RC t :: * -> Constraint -- Short for Reified Constraint
reify# :: forall r. (RC t a => r) -> t a -> r
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org
] On Behalf Of David
| Feuer
| Sent: 11 December 2016 05:01
the
overloading. It would be worth asking how you might access that
information.
#11195 looks like a practically important and serious performance
problem. I know you spent some time investigating it months ago; do
you have any more recent progress to report? Do you know if the
problem is still
y) `orElse` checkInv i
David Feuer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
#x27; :: forall a r . (forall (n :: Nat) . KnownNat n => Tagged n
r) -> Integer -> r
reifyNat' f = reify# (Constrain (unTagged (f :: Tagged n r)) :: forall
(n :: Nat) . Constrain (KnownNat n) r)
On Thu, Dec 22, 2016 at 6:55 PM, David Feuer wrote:
> On Thu, Dec 22, 2016 at 4:58 PM,
On Thu, Dec 22, 2016 at 4:58 PM, Edward Kmett wrote:
> On Mon, Dec 12, 2016 at 1:31 PM, David Feuer wrote:
>>
>> On Dec 12, 2016 1:15 PM, "Edward Kmett" wrote:
>>
>> A few thoughts in no particular order:
>>
>> Unlike this proposal, the existi
ec 21, 2016 at 2:14 PM, Index Int wrote:
>
>> There's a related GHC Proposal:
>> https://github.com/ghc-proposals/ghc-proposals/pull/27
>>
>> On Wed, Dec 21, 2016 at 10:04 PM, David Feuer
>> wrote:
>> > In the Old Days (some time before Haskell 98), `s
instance Traversable t => Traversable (F t) where
traverse = travTraverse
trav = retrav getF trav
instance Traversable t => Traversable (G t) where
traverse = travTraverse
trav = retrav getG trav
instance Traversable t => Traversable (H t) where
traverse = travTraverse
tional erasure could cause "laziness safety" issues, but
the system would be essentially unusable without it.
4. What would the language extension do, exactly?
a. Automatically satisfy Seq for data types and families.
b. Propagate Seq constraints using the usual rules and the special
)
> other direction is true though.
I was definitely imagining them as first-class types; your point that
f x /~ f y => x /~ y even if f is a type family is an excellent one.
> Also:
>
> f x ~ a -> b, is true with f ~ (->) a, x ~ b.
Whoops! Yeah, I momentarily forgot that (-
According to Ben Gamari's wiki page[1], the new Typeable is expected to
offer
eqTypeRep :: forall k (a :: k) (b :: k). TypeRep a -> TypeRep b -> Maybe (a
:~: b)
Ideally, we'd prefer to get either evidence of equality or evidence of
inequality. The traditional approach is to use Dec (a :~: b), whe
On Dec 12, 2016 1:15 PM, "Edward Kmett" wrote:
A few thoughts in no particular order:
Unlike this proposal, the existing 'reify' itself as core can actually be
made well typed.
Can you explain this?
Tagged in the example could be replaced with explicit type application if
backwards compatibi
ot see, at compile time, that the result is 15. If I write
reify (+1) $ \p -> reflect p x
then GHC will never inline the application of (+1). Etc.
I'd like to replace reify' with reify# to avoid this problem.
Thanks,
David Feuer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
different trade-offs.
On Oct 11, 2016 1:50 AM, "Carter Schonwald"
wrote:
> How is that not a bug? We should be able to read back floats
>
> On Monday, October 10, 2016, David Feuer wrote:
>
>> It doesn't, and it never has.
>>
>> On Oct 10, 2016
It doesn't, and it never has.
On Oct 10, 2016 6:08 PM, "Carter Schonwald"
wrote:
> Read should accept exactly the valid source literals for a type.
>
> On Monday, October 10, 2016, David Feuer wrote:
>
>> What does any of that have to do with the Read instanc
. That's of course ignoring denormalized floats, infinities,
> negative zero and perhaps nans.
>
> At the very least we need to efficiently and safely support everything but
> nan. And I have some ideas for that I hope to share soon.
>
> On Monday, October 10, 2016, David Fe
more difficult to achieve
than one might think - floating point is deceivingly tricky. There are
already several good parsers in the libraries, but I believe all of
them can provide different results than literals in some cases.
YItz
On Sat, Oct 8, 2016 at 10:27 PM, David Feuer wrote:
> The
The current Read instances for Float and Double look pretty iffy from an
efficiency standpoint. Going through Rational is exceedingly weird: we have
absolutely nothing to gain by dividing out the GCD, as far as I can tell.
Then, in doing so, we read the digits of the integral part to form an
Intege
ep 7, 2016 at 4:46 PM, Simon Peyton Jones
wrote:
> I can advise about how (see comment:9 of #1965). I can only see how to do it
> in an un-typed way in the back end.
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf
I'd like to place a small bounty on
https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS .
If someone implements this request by GHC 8.2, I will buy them 24
bottles of high-end root beer (e.g., Maine Root) or something of
similar value agreeable to both parties. (*)
Thanks,
Currently, the only way to suppress custom warnings and deprecations is
with -fno-warn-warnings-deprecations, which is a rather large hammer. I see
two ways we can improve this, and I propose that we should do both.
1. Per-binding suppression
Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-
:: Monoid (f a) => f a -> f a -> f a
> op = (<>)
>
>
> ? Does that do what you like?
>
> Richard
>
>
> On Sep 1, 2016, at 11:15 PM, David Feuer wrote:
>
> On occasion, it can be useful to have default definitions that don't
> typecheck even with De
On occasion, it can be useful to have default definitions that don't
typecheck even with DefaultSignatures. It would be nice to be able to use
them anyway. For example, if we have
class Semigroup1 f where
op :: f a -> f a -> f a
then we could, hypothetically, give a default definition for (<>):
I'm glad to see I'm not the only one who wants this!
On Wed, Aug 24, 2016 at 6:13 PM, Edward Z. Yang wrote:
> I filed a ticket for precisely this:
>
> https://ghc.haskell.org/trac/ghc/ticket/12203
>
> Edward
>
> Excerpts from David Feuer's message of 2016-08-24 18:11:16 -0400:
>> I'm trying t
I'm trying to write a bidirectional pattern synonym which is morally
simple, but as far as I can tell there's no way to write it as a
simple bidirectional pattern synonym.
What I want to say is
pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs)
(where TSnocList and Dual are both n
Excellent!
On Aug 5, 2016 2:32 PM, "Edward Kmett" wrote:
> Done and done! Retroactively. How is that for service? =)
>
> -Edward
>
> On Fri, Aug 5, 2016 at 2:08 PM, David Feuer wrote:
>
>> I know there's been some discussion about letting users select t
I know there's been some discussion about letting users select the deriving
mechanism they want, but I'd like to propose a separate tweak to the
defaults. Specifically, it's annoying to have to use three pragmas to let
me write
newtype Foo f a = Foo (f a) deriving (Functor, Foldable, Traversable)
It seems to me that equality constraints could potentially be supported by
an implementation with neither GADTs nor type families. Type families don't
really seem to have much to do with it, and GADTs are strictly heavier
(GADTs ~= ExistentialQuantification + TypeEquality).
Could we get a separate
Currently, containers does not depend on transformers, so it has to
duplicate its functionality or just do without. Since transformers is also
a GHC boot package, I believe it should be feasible to make containers
depend on it. To what extent would that reduce
parallelizability of GHC builds or oth
I meant reflection in the sense of the reflection package. Sorry for the
confusion.
On Jun 19, 2016 4:28 AM, "Ben Gamari" wrote:
> "Edward Z. Yang" writes:
>
> snip
>
> >> Dictionaries are harder to come by,
> >> but reflection might be an option.
> >
> > If I understand correctly, even if you h
pickering.github.io/posts/2016-06-18-why-no-refinement.html
>
> Matt
>
> On Fri, May 27, 2016 at 4:50 AM, David Feuer
> wrote:
> > Scratch that. I think you might be right.
> >
> > On May 25, 2016 8:40 PM, "David Feuer" wrote:
> >>
> >&g
Mostly I'm looking for a rough estimate. Some false positives and
false negatives are tolerable. If I have something like
f :: Int -> Maybe String -> String
f _ Nothing = "Hi there!"
f n (Just b) = if n > 0 then show b else "whatever"
then I'd likely be interested in a warning about the fact that
n't quite understand what you mean by
> "conditionally strict" in an argument though.
>
> -Edward
>
> On Sat, May 28, 2016 at 8:00 PM, David Feuer
> wrote:
>
>> There are certain patterns of strictness or laziness that signal the need
>> for extra
There are certain patterns of strictness or laziness that signal the need
for extra caution. I'm wondering whether it might be possible to offer
warnings for different varieties of them, and pragmas suppressing the
warnings at the relevant sites. Some function behaviors that suggest extra
care:
1.
Scratch that. I think you might be right.
On May 25, 2016 8:40 PM, "David Feuer" wrote:
> Partially. Unfortunately, bidirectional pattern synonyms tie the types of
> the pattern synonyms to the types of the smart constructors for no good
> reason, making them (currently)
101 - 200 of 315 matches
Mail list logo
