coerce works when one type is a newtype wrapper for another, not when two types happen to share the same runtime representation. I don't think ghc can currently prove the latter except in the case of newtypes, especially in the presence of optimizations.On Wed, Dec 2, 2020 at 11:33 AM Brent Walker <brenthwalker@gmail.com> wrote:My question was on how to use coerce -- not whether this is worth doing or not. If we were discussing that, then I would say it's not 'just a leaf' -- it's ALL the leaves of the tree -- and for a tree of depth n, there are 2^n of them so depending on what 'n' is, it could potentially be something to worry about._______________________________________________On Wed, Dec 2, 2020 at 6:00 PM Henning Thielemann <lemming@henning-thielemann.de> wrote:
On Wed, 2 Dec 2020, Brent Walker wrote:
> In the following code, function fmap does not compile because variable
> 'y' on line marked <***> has type (Expr a) where an (Expr b) is
> expected. The code can be fixed simply by returning (Val x) on the rhs
> of the function but then we are allocating a new object for something we
> could potentially reuse since (Val n) has the same runtime
> representation in (Expr a) and (Expr b) (it has no dependence on the
> type variable).
Is it worth the trouble? It is only a leaf of the tree.
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.--_______________________________________________brandon s allbery kf8nh
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.