| I'm working on unlifted newtypes.
|
| In MkId.mkDataConWorkId, I see
|
| > mkDataConWorkId wkr_name data_con
| > | isNewTyCon tycon
| > = mkGlobalId (DataConWrapId data_con) wkr_name wkr_ty nt_work_info
| > | otherwise
| > = mkGlobalId (DataConWorkId data_con) wkr_name wkr_ty alg_wkr_info
|
| Why is a newtype worker called a wrapper (DataConWrapId)? Note that some
| newtype constructors have separate wrappers (which is relatively new).
| This doesn't appear to be hurting anything right now, but it's odd, and
| there's no commentary on this.
That is indeed odd, I agree.
Some points
* Newtypes can have wrappers: see Note [Data con wrappers and GADT syntax]
in MkId.hs
* The "worker" for a newtype data constructor is just a function
with a compulsory unfolding, of form (\x. x |> co), where co
is the newtype coercion.
* I agree that it's not right to describe the "worker" for a newtype
data constructor as a "DataConWrapId"; after all, it may have
a wrapper too (see previous bullet).
* Bu not is it rigt to call it a regular DataConWorkId. Those are
*data* constructors, head normal forms, very very special.
The kosher thing would be to create a NewtypeWorkId. But that's seems a terrible fiddle, because these things are inlined compulsorily so they never exist for long.
Maybe it should just be a vanilla Id. While there are a few places where
we do test for data-con-wrap-ids -- eg in isImplicitId -- but remember that these things are inlined so aggressively that we will only see them very briefly.
Or leave it as-is, with the above commentary as a Note -- that might be the easiest thing! Might you make a little patch?
Simon
| -----Original Message-----
| From: Richard Eisenberg