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
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 allbery.b@gmail.com