[m-dev.] mini types

[Zoltan Somogyi]

2020-05-31 12:43 GMT+10:00 Peter Wang<novalazy at gmail.com>:
>> The first approach is to reserve the names of some enum types defined
>> in the Mercury library, and simply not allow users to define types
>> with those names. The names would certainly include enum, but the library
>> also defines a whole bunch of other enum types:
> 
> By "enum" I suppose you meant "bool".

Yes.

>> comparison_result                           in builtin.m
>> day_of_week                                 in calendar.m,
>> noncanon_handling                           in deconstruct.m
>> whence                                      in io.m and stream.m
>> access_type, file_type, whence              in io.m
>> stream_content, stream_mode                 in io.m
>> integer_base, integer_size, signedness      in lexer.m and term.m
>> assoc                                       in ops.m
>> poly_kind, string_format_flag_*             in string.parse_util.m
>> *_status                                    in table_builtin.m
>> adjacent_to_graphic_token                   in term_io.m
>> dst                                         in time.m
>> 
>> and it is far from clear whether we would want to reserve any of these
>> (with the exception of the ones that are *already* defined in more than
>> one module :-()
> 
> I don't agree with this option. Apart from an introducing possibly an
> ever expanding set of reserved names, most if not all of those types
> would not benefit from being packed into other types anyway.

As the "far from clear" indicates, I don't like this option either.
I put up that list specifically to illustrate the point you made explicitly.

>> 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.

> 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, regardless of whether
the type definition that we use for C is a Mercury definition,
a C foreign type definition, or a C foreign enum definition.
Obviously, the compiler could check only the first of those.
We therefore would want to *require* that the named type
be defined in Mercury when targeting C, since the consequence
of getting such an assertion wrong for a foreign definition
would be silent data corruption planting a time bomb that would be
*very* hard to debug.

>> - 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.

>> Opinions?
> 
> Another option is to do nothing, as the payoff is unclear.

Of course. However, the only way to evaluate the payoff is to actually
implement the feature, at least partially.

Zoltan.