[m-dev.] mini types

[Peter Wang]

On Sun, 31 May 2020 13:03:29 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> >> The other approach is to allow programmers to indicate that a type
> >> with a given name has a size of N bits. This could be done in several ways:
> >> 
> >> - a pragma such as ":- pragma type_size(enum, 1)."
> > 
> > I'm confused by the "enum".
> 
> Again, that should have been ":- pragma type_size(bool, 1). Sorry for
> the confusion.
> 
> > The pragma should be required on t3 in your
> > example above, but not required on bool, correct?
> 
> 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.

> > The pragma might need a foreign language qualifier.
> 
> 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.

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.

> 
> >> - a compiler option such as --type-size enum=1
> >> 
> >> - a compiler option such as --type-sizes <type_size_file>, where the
> >>   type_size_file contains lines such as "enum 1".
> >> 
> > 
> > Both just seem error prone. In my opinion that information belongs in
> > the source file, close to the type definition. It's far harder to touch
> > a source file without the build system taking notice.
> 
> 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.

Peter