d data type contexts being needed in the language for bang
patterns. :(
>
> -Edward
>
> On Apr 1, 2014, at 5:26 PM, John Lato wrote:
>
>> Hi Edward,
>>
>> Yes, I'm aware of that. However, I thought Dan's proposal especially
droll given that changing seq t
ought Dan's proposal especially droll
> given that changing seq to a class-based function would be sufficient to make
> eta-reduction sound, given appropriate instances (or lack thereof). Meaning
> we could leave the rest of the proposal unevaluated (lazily!).
>
> And if somebody
Hi Edward,
Yes, I'm aware of that. However, I thought Dan's proposal especially droll
given that changing seq to a class-based function would be sufficient to
make eta-reduction sound, given appropriate instances (or lack thereof).
Meaning we could leave the rest of the proposal u
element in the list. This has been fixed in 7.8, but there
>> are
>> other examples. I believe lens, [1] for instance, has some stuff in it
>> that
>> works very hard to avoid this sort of cost; and it's not always as easy
>> to avoid
>> as the above ex
as been fixed in 7.8, but there
>> are
>> other examples. I believe lens, [1] for instance, has some stuff in it
>> that
>> works very hard to avoid this sort of cost; and it's not always as easy
>> to avoid
>> as the above example. Composing with a
pe wrapper, for instance,
> causes an
> eta expansion that can only be seen as such at the core level.
>
> The obvious solution is: do eta reduction. However, this is not
> operationally
> sound currently. The problem is that seq is capable of telling the
> difference
> between
that can only be seen as such at the core level.
The obvious solution is: do eta reduction. However, this is not
operationally
sound currently. The problem is that seq is capable of telling the
difference
between the following two expressions:
undefined
\x -> undefined x
The former ca
ly 2010 17:46
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.org
Subject: Re: Casting + eta reduction
Or a different way:
I want -fdo-lambda-eta-expansion (which, if I understand correctly, actually
triggers eta *reduction*) to eliminate argument casts, as well.
My motivation: I'
Or a different way:
I want -fdo-lambda-eta-expansion (which, if I understand correctly, actually
triggers eta *reduction*) to eliminate argument casts, as well.
My motivation: I'm working on a generalized trie library, and due to
http://hackage.haskell.org/trac/ghc/ticket/4185, I can&
09 July 2010 03:30
> *To:* glasgow-haskell-users@haskell.org
> *Subject:* Casting + eta reduction
>
>
>
> Consider
>
>
>
> newtype Foo = Foo Int
>
>
>
> lift :: (Int -> a) -> Foo -> a
>
> lift f (Foo x) = f x
>
>
>
&
Subject: Casting + eta reduction
Consider
newtype Foo = Foo Int
lift :: (Int -> a) -> Foo -> a
lift f (Foo x) = f x
Now, I'd expect this to compile with -O2 down to something like
lift f = f `cast` (Foo -> a)
but it doesn't.
It seems that GeneralizedNewtypeDeriving
On Thu, Jul 08, 2010 at 09:30:23PM -0500, Louis Wasserman wrote:
> Consider
>
> newtype Foo = Foo Int
>
> lift :: (Int -> a) -> Foo -> a
> lift f (Foo x) = f x
>
> Now, I'd expect this to compile with -O2 down to something like
>
> lift f = f `cast` (Foo -> a)
>
> but it doesn't.
>
> It seems
Consider
newtype Foo = Foo Int
lift :: (Int -> a) -> Foo -> a
lift f (Foo x) = f x
Now, I'd expect this to compile with -O2 down to something like
lift f = f `cast` (Foo -> a)
but it doesn't.
It seems that GeneralizedNewtypeDeriving assumes that these two things *are*
equivalent, and it just
13 matches
Mail list logo
