[m-dev.] mini types

[Zoltan Somogyi]

2020-06-01 14:04 GMT+10:00 Peter Wang<novalazy at gmail.com>:
>> It would be required on t3. Unless we reserve "bool" so that it can
>> *only* refer to the bool defined in the Mercury standard library,
>> which neither of us seems to like, it would be required for bool as well.
>> 
> 
> Can you explain why it would be required on bool? I understand from
> your other message that for a simple type like bool, the compiler will
> (still) include type representation information into the .int3 file,
> which would be available when it comes time to verify the type_size
> assertion on t3.

If the module (say A) imports bool, then the compiler

- will not read bool.int3, or any other .int3 file, when generating A.int3, but

- will read bool.int3, and the .int3 files of the other modules A imports,
  when generating A.int and A.int2 (mmc --make-interface A.m generates
  both).

We would need the information about bool's size when generating A.int3.
This means we *can't* get it from bool.int3 at that time. We *could* get it
from a pragma, and the compiler could verify that the pragma does not lie
when generating A.int.

We can't get the compiler to read the .int3 files of all the modules
imported by A, because some of those modules can import A,
which would set up a circular dependency.

>> Argument packing is applicable only when targeting C.
>> So the meaning of the assertion is that the named type occupies
>> the given number of bits when targeting C,
> 
> My suggestion was because the name of the assertion doesn't say anything
> about the target that it applies to. Perhaps it's not necessary.

No, you are right; the pragma should specify that it is for C. I was just saying
that we don't need any such pragma for any of our other current target
languages.

> And, at least previously, there could be multiple data representations
> for a single foreign language (hlc vs hl) so just adding "C" on the
> assertion wouldn't be quite right either.

I think we can safely leave off worrying about that when we add a *third*
backend that generates C, or changing either of the existing ones to support
yet another data representation. I for one don't see either of those happening
any time soon.

>> I fully agree wrt --type size. As for --type-sizes, it would be error prone
>> in that users may forget to set up a dependency such as
>> 
>> $(program.ints): type_size_file
>> 
>> or its mmc --make equivalent, but once that setup is done, it should be
>> pretty foolproof.
>> 
> 
> mmc --make doesn't have an equivalent.

If we chose that approach, we would have to add one. But it seems that
everyone is gravitating towards the pragma approach being preferred
over either of the approaches that rely on options.

Zoltan.