[m-dev.] mini types

[Peter Wang]

On Sat, 30 May 2020 09:09:43 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> When we build .int3 files, the only input is the module's source file;
> we don't read any interface files. This means that when we see
> a definition like
> 
> :- type t3
>     --->    t1_f1(bool, int8)       % arguments take 9 bits
>     ;       t1_f2(bool, bool, bool) % arguments take 3 bits
> 
> the compiler at present has no idea what type "bool" refers to, which means
> it cannot assume that it is sub-word-sized, which means that it cannot
> recognize that t3 is also a mini type.
> 
> I can see two broad approaches that will let the compiler recognize t3
> as a mini type when building the .int3 file.
> 
> 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".

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

> 
> 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". The pragma should be required on t3 in your
example above, but not required on bool, correct?

The pragma might need a foreign language qualifier.

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

> In all these cases, the compiler would *assume* that the assertion given by
> the programmer is true when generating the .int3 file, but would *check*
> whether the assertion is true when generating the .int file (when it has
> all the info needed for this), generating an error for each failed assertion.
> 
> To make maximal use of mini types, the compiler would want to know whether
> values of a mini type can be compared as a whole, as a single N-bit unsigned
> number, which is possible only in special circumstances (all arguments have
> to be themselves comparable as unsigned, and the type has to have either
> just one function symbol, or one constant and one nonconstant function symbol,
> in that order). This means that e.g. the pragmas above should have room
> for an assertion to this effect, as in ":- pragma type_size(enum, 1,
> comparable_as_unsigned).".
> 
> The first approach is easier to implement, but the second is more general,
> since it works for types that are defined outside the Mercury standard library.
> I therefore prefer the second approach.
> 
> Opinions?

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

Peter