Re: Why isn't this Typeable?

to the generalization I describe, so I wanted to check first how much that matters. David FeuerWell-Typed, LLP Original message From: Richard Eisenberg <r...@cs.brynmawr.edu> Date: 9/25/17 2:42 PM (GMT-05:00) To: David Feuer <da...@well-typed.com> Cc: Ben Gamari

Re: Why isn't this Typeable?

he > implementation is doing the right thing here. > > Richard > > > On Sep 24, 2017, at 5:45 AM, David Feuer <da...@well-typed.com> wrote: > > > > data Foo :: (forall a. a -> Maybe a) -> Type > > > > Neither Foo nor Foo 'Just is Typeable. T

Re: RTS changes affect runtime when they shouldn’t

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

Re: Why isn't this Typeable?

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

Why isn't this Typeable?

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

Help with #14140

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___

Re: Type-level generics

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

Re: Type-level generics

siderably 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 several weeks that it mig

Type-level generics

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

RE: [commit: ghc] master: Adjust test suite stats (a055f24)

lGdfo%3D=0 | | >--- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer <david.fe...@gmail.com> | Date:   Mon Aug 28 14:35:19 2017 -0400 | | Adjust test suite stats | | T1969 and T12150 were fai

Re: New primitive types?

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

Tying knots with strict constructors

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# documentation

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,

Re: Repeated computations under a lambda

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

Re: [ANNOUNCE] GHC 8.2.1 release candidate 3 available

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.

More TRAC ticket statuses?

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

Re: Hunting down a compilation performance regression involving type families

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

Re: Trees that Grow in the hsSyn AST

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. >

RE: Trees that Grow in the hsSyn AST

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

Re: Where do I start if I would like help improve GHC compilation times?

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

Re: testsuite not in GHC 8.2.1-rc1 source tarball ?

Original message From: George Colpitts <george.colpi...@gmail.com> Date: 4/6/17 9:39 AM (GMT-05:00) To: David Feuer <da...@well-typed.com>, Jens Petersen <juhpeter...@gmail.com>, Ben Gamari <b...@well-typed.com> Cc: GHC developers <ghc-devs@haskell.o

Re: GHC 8.2.1-rc1 source tarball availability

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:

Re: DeriveFoldable treatment of tuples is surprising

onsistent. Is it more > consistent 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

DeriveFoldable treatment of tuples is surprising

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

Bounding I/O imprecision

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

RE: Another strictness analysis wrinkle

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 <da...@well-typed.com> Date: 3/15/17 6:38 AM (GMT

Another strictness analysis wrinkle

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

RE: Removing core-spec.pdf from repository?

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

What should and should not be marked has_side_effects?

s 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 these read-only ops has_side_effects=False

Getting exceptions right

/FixingExceptions Thanks, David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows build broken

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

Proposal: make throwIO and throw strict

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

Datacon RULES test

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? Thanks, David Feuer

Re: Status of early-inline branch

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 you could give me a sens

Status of early-inline branch

. Thanks, David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Early inline

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:

Re: Static data and RULES

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 #-} > > {-# RULES “L” m

Re: Static data and RULES

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

RE: Static data and RULES

to 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 16, 2017 7:

RE: Static data and RULES

S the proposed new scheme? > > > > I’m lost > > > > Simon > > > > *From:* David Feuer [mailto:david.fe...@gmail.com] > *Sent:* 16 February 2017 23:51 > *To:* Simon Peyton Jones <simo...@microsoft.com> > *Cc:* ghc-devs <ghc-devs@haskell.org>;

RE: Static data and RULES

e problem you 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

Re: Static data and RULES

:20 PM (GMT-05:00) To: ghc-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 wr

Static data and RULES

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

eagerlyBlackhole# efficiency thought

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

Re: Lazy ST vs concurrency

will add those to the differential. Original message From: Simon Marlow <marlo...@gmail.com> Date: 1/31/17 3:59 AM (GMT-05:00) To: Simon Peyton Jones <simo...@microsoft.com> Cc: David Feuer <da...@well-typed.com>, ghc-devs@haskell.org Subject: Re: Lazy

Re: Constant functions and selectors make for interesting arguments

all > like 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

Re: Lazy ST vs concurrency

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

Re: Constant functions and selectors make for interesting arguments

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 <ghc-devs@haskell.org> > Subject: Constant functions and selecto

Re: Lazy ST vs concurrency

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

Lazy ST vs concurrency

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

Constant functions and selectors make for interesting arguments

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

RE: Floating lazy primops

imo...@microsoft.com> Date: 1/23/17 4:47 PM (GMT-05:00) To: David Feuer <da...@well-typed.com> 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 argument

Re: Magical function to support reflection

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@haskell.org http

Re: Magical function to support reflection

t 10:45 AM, 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.

RE: Magical function to support reflection

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 <ghc-devs-boun...@haskell.org>] On Behalf Of David | Feuer | Sen

Pattern checker status

. 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 there? David Feuer

Can the definition of alwaysSucceeds be streamlined?

rElse` checkInv i David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Magical function to support reflection

. (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 <david.fe...@gmail.com> wrote: > On Thu, Dec 22, 2016

Re: Magical function to support reflection

On Thu, Dec 22, 2016 at 4:58 PM, Edward Kmett <ekm...@gmail.com> wrote: > On Mon, Dec 12, 2016 at 1:31 PM, David Feuer <david.fe...@gmail.com> wrote: >> >> On Dec 12, 2016 1:15 PM, "Edward Kmett" <ekm...@gmail.com> wrote: >> >> A few thou

Re: Retro-Haskell: can we get seq somewhat under control?

d, Dec 21, 2016 at 2:14 PM, Index Int <vlad.z.4...@gmail.com> 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 <david.fe...@gmail.com> >> wrote: >> &

Improving DeriveTraversable

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 trav = retrav get

Retro-Haskell: can we get seq somewhat under control?

em 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 Coercible rule. c. Modify the translation of strict fields to add Seq const

Explicit inequality evidence

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),

Re: Magical function to support reflection

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

Magical function to support reflection

5. 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

Re: Reading floating point

trade-offs. On Oct 11, 2016 1:50 AM, "Carter Schonwald" <carter.schonw...@gmail.com> wrote: > How is that not a bug? We should be able to read back floats > > On Monday, October 10, 2016, David Feuer <david.fe...@gmail.com> wrote: > >> It doesn't, and it

Re: Reading floating point

ore 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 <david.fe...@gmai

Reading floating point

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

Custom warning suppression

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,

Re: Unprincipled defaults

default op :: 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 <david.fe...@gmail.com> wrote: > > On occasion, it can be useful to have default definitions

Unprincipled defaults

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

Re: Rewrapping with simple bidirectional pattern synonyms

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

Rewrapping with simple bidirectional pattern synonyms

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

Re: Deriving tweaking

Excellent! On Aug 5, 2016 2:32 PM, "Edward Kmett" <ekm...@gmail.com> wrote: > Done and done! Retroactively. How is that for service? =) > > -Edward > > On Fri, Aug 5, 2016 at 2:08 PM, David Feuer <david.fe...@gmail.com> wrote: > >> I know there's b

Deriving tweaking

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)

Can we offer ~ without GADTs or type families?

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

How bad would it be for containers to depend on transformers?

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

Re: Optimizing "counting" GADTs

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. > > > >

Re: Optimizing "counting" GADTs

. > > http://mpickering.github.io/posts/2016-06-18-why-no-refinement.html > > Matt > > On Fri, May 27, 2016 at 4:50 AM, David Feuer <david.fe...@gmail.com> > wrote: > > Scratch that. I think you might be right. > > > > On May 25, 2016 8:40 PM, "

Re: Strictness/laziness warnings

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

Re: Strictness/laziness warnings

ed. I don'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 <david.fe...@gmail.com> > wrote: > >> There are certain patterns of strictness or laziness that sign

Strictness/laziness warnings

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:

Re: Optimizing "counting" GADTs

Scratch that. I think you might be right. On May 25, 2016 8:40 PM, "David Feuer" <david.fe...@gmail.com> wrote: > Partially. Unfortunately, bidirectional pattern synonyms tie the types of > the pattern synonyms to the types of the smart constructors for no good > reaso

Re: Optimizing "counting" GADTs

, "Carter Schonwald" <carter.schonw...@gmail.com> wrote: could this be simulated/modeled with pattern synonyms? On Wed, May 25, 2016 at 7:51 PM, David Feuer <david.fe...@gmail.com> wrote: > I've started a wiki page, > https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADT

Optimizing "counting" GADTs

I've started a wiki page, https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADTs , to consider optimizing GADTs that look like natural numbers but that possibly have "heavy zeros". Please take a look. ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David > Feuer > | Sent: 24 May 2016 23:14 > | To: Carter Schonwald <carter.schonw...@gmail.com> > | Cc: ghc-devs <ghc-devs@haskell.org> > | Subject: Re: Unpacking sing

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

nal Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David > Feuer > | Sent: 24 May 2016 23:14 > | To: Carter Schonwald <carter.schonw...@gmail.com> > | Cc: ghc-devs <ghc-devs@haskell.org> > | Subject: Re: Unpacking single-field, single-strict

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

<carter.schonw...@gmail.com> wrote: > Phrased differently: there's a subclass of existential data types which have > a well behaved unboxed memory layout? > > @ David : have you tried simulating this in userland using eds structs / > structures lib? > > On Tuesday, May 24,

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

, it'll do. David Feuer <david.fe...@gmail.com> writes: > Given > > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the > Small types are (possibly recursive) sums, it's generally possible to > express that as something like > > data Selector = One | Two |

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

wrote: > David Feuer <david.fe...@gmail.com> writes: > >> Not really. It's really just the newtype optimization, although it's not a >> newtype. > > Ahh, I see. Yes, you are right. I was being silly. > > However, in this case wouldn't it make more sense to jus

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

Not really. It's really just the newtype optimization, although it's not a newtype. On May 24, 2016 12:43 PM, "Ben Gamari" <b...@well-typed.com> wrote: > David Feuer <david.fe...@gmail.com> writes: > > > Given > > > > data Big a = B1 !(Smal

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

I meant about "unpacking". But for efficiency purposes, that wrapper needs the newtype optimization. On May 24, 2016 4:16 AM, "Ben Gamari" <b...@well-typed.com> wrote: > David Feuer <david.fe...@gmail.com> writes: > > > Data.IntMap could be cleaned up some if single-fiel

Unpacking single-field, single-strict-constructor GADTs and existentials

Data.IntMap could be cleaned up some if single-field, single strict constructor GADTs/existentials could be unpacked even when wrapping a sum type. We could then have data Status = E | NE data IntMap' (s :: Status) a where Bin :: ... -> ... -> !(IntMap' NE a) -> !(IntMap' NE a) -> IntMap' NE a

Re: suboptimal ghc code generation in IO vs equivalent pure code case

Well, a few weeks ago Bertram Felgenhauer came up with a version of IO that acts more like lazy ST. That could be just the thing. He placed it in the public domain/CC0 and told me I could put it up on Hackage if I want. I'll try to do that this week, but no promises. I could forward his email if

Can we do something slightly nicer about (^)?

Every time someone writes, say, x^20, the literal exponent defaults to Integer. This is the wrong default whenever the literal is in the Word range. Fixing this goes beyond the capabilities of RULES pragmas, but I imagine it would be a fairly simple thing to accomplish in the internal rule

Re: Pattern synonym type flexibility

just a regular old Haskell value! The only special bit is that it's treated, syntactically, as a constructor. There's simply nothing else worth saying about it, so the less said the better. On Apr 20, 2016 1:48 PM, "David Feuer" <david.fe...@gmail.com> wrote: > I don't know what

Re: Pattern synonym type flexibility

, 2016 1:41 PM, "Carter Schonwald" <carter.schonw...@gmail.com> wrote: Shouldn't the design simply be both directions are the dual of the other, and pure in some sense ? On Wednesday, April 20, 2016, David Feuer <david.fe...@gmail.com> wrote: > To some degree, it probabl

Re: Pattern synonym type flexibility

would be free to do some things that "don't make sense", and that doesn't bother me in the least. On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonw...@gmail.com> wrote: > Would that duality be related to the given vs wanted constraints ? > > On Wed

Pattern synonym type flexibility

As far as I can tell from the 7.10 documentation, it's impossible to make a bidirectional pattern synonym used as a constructor have a different type signature than when used as a pattern. Has this been improved in 8.0? I really want something like class FastCons x xs | xs -> x where fcons :: x

Could we promote unlifted tuples?

types can be used would presumably translate directly to restrictions on how types of unlifted tuple kind can be used. David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

<    1   2   3   >