[m-dev.] pragma foreign_export_enum

[Julien Fischer]

On Tue, 28 Nov 2017, Zoltan Somogyi wrote:

> On Tue, 28 Nov 2017 11:58:15 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>>> I have been working on making the infrastructure for type representations
>>> more flexible, since this is needed to enable more compact data representations.
>>
>> Are there some concrete proposals for what these more compact data
>> representations are?
>
> One is extending the current algorithm that puts several adjacent enum arguments
> of a term into a single word to also treat {int,uint}{8,16,32} arguments as
> sub-word-sized entities that can be packed into a single 64 bit word.
> (Mutatis mutandis for 32 bit platforms.)
>
> Another is Peter's proposal in Mantis 432: representing terms such as
> f(bool, bool) in a single word by storing the sub-word arguments
> next to the primary tag. And the obvious extension with small ints.
>
> A third is to make packing sub-word-sized arguments together more
> effective by reordering the arguments to put them next to each other.
> Currently, a term such as f(bool, int, bool) requires a three word cell;
> reordering it as f(int, bool, bool) reduces that to two.
>
> A fourth is a version of Mantis 432 that would be effective only
> in the presence of such reordering, and when the type has many
> non-constant function symbols: storing sub-word-sized arguments
> next to the *secondary* tag in heap cells.

I would like to propose a fifth (somewhat related to the first): records
that are really vectors of fixed size integer types, for example:

    :- type foo ---> foo(uint32, uint32, uint32, uint32).

    :- type ipv4_addr ---> ipv4_addr(uint8, uint8, uint8, uint8).

should (in C grades at least) be packed into a word if they will fit, or
represented as an array of the fixed size integer type.  Additionally,
there should be a well defined mechansim for accessing the fields of
those types from foreign language code.  For C grades, the fact that
the word size may vary is a bit of a complication, but I think we could
arrange (perhaps via an additional pragma) for the compiler to generate
a macro that always returns a pointer to an array of fixed size integer
types regardless of whether the machine uses 32- or 64-bit words.

>>> In the process, I have come across something odd that I need resolved.
>>>
>>> Section 14.5 of the language reference manual, for foreign_export_enum pragmas,
>>> states (near the end) that
>>>
>>> "It is an error if the mapping between constructors and symbolic names
>>> does not form a bijection. A program can contain multiple ‘pragma foreign_export_enum’
>>> declarations for a single Mercury type. The implementation is not required to check
>>> that the symbolic names generated by separate ‘pragma foreign_export_enum’
>>> declarations are unique."
>>>
>>> The second sentence is a bit ambiguous; it does not say whether you can have
>>> code like this:
>>>
>>> :- pragma foreign_export_enum("C", type_foo/0, [prefix("FOO_")]).
>>> :- pragma foreign_export_enum("C", type_foo/0, [prefix("BAR_")]).
>>>
>>> or whether having two foreign_export_enum (fee for short) pragmas for the
>>> same type is allowed ONLY if they are for different target languages.
>>
>> The intention was that you may have multiple foreign_export_enum pragmas
>> for the same type as above.  If you do, then the corresponding symbols
>> in each set are synonyms.
>>
>> The bit about the bijection was intended to refer to the mapping
>> established by each fee pragma _in isolation_; they are not meant be
>> considered collectively.
>
> That was not at all clear from the wording, which I suspect was cut-and-pasted
> from the section of foreign_enums. I will change the description.

That cut-and-pasting seems unlikely as foreign_export_enum was implemented
before foreign_enum ;-)

> Any objection to moving the documentation of foreign_enum before
> the documentation of foreign_export_enum, i.e. swapping the order
> of 14.5 and 14.6? I think that would make the distinction between the two
> easier to describe.

Not from me.

Julien.