[m-dev.] question about data representation decisions
jfischer at opturion.com
Sun Apr 1 14:41:43 AEST 2018
On Fri, 30 Mar 2018, Zoltan Somogyi wrote:
> At the moment, each invocation of the compiler decides
> the representation of every du type visible in the current module,
> whether or not the type is *defined* in the current module.
> This means that if a type foo is visible in five modules,
> the compilations of all five modules must *independently* make
> the same decision. They obviously use the same algorithm,
> but they need the same data as well. This is why we sometimes
> bust abstraction boundaries. If a module abstract exports a type bar
> and privately defines bar as an equivalence to float, then any du type
> foo it defines that contains a field of type bar will cause this module
> to reserve *two* words for that field on 32 bit machines, while
> compilations of other modules will reserve only the standard *one* word
> for that field, *unless* the equivalence is exported.
> I propose that we switch to a different approach. Instead of
> recording in interface files the *information needed to reach
> the right decisions* about data type representations, we should
> record *the decisions themselves*. This would require adding
> a new kind of item that can occur only in compiler generated
> interface files, but we agreed several months ago that that is ok.
I have no objections to this.
More information about the developers