[m-users.] Mercury macro trouble

[Julien Fischer]

On Mon, 27 May 2024 at 03:39, Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Sonntag, dem 26.05.2024 um 15:01 +1000 schrieb Julien Fischer:

> > > The obvious solution would be to use inline C functions with the same names
> > > as the macros, instead. Gcc's statement expressions aren't needed.
> > >
> > > So I'm asking the Mercury team to scrap all those macros and use inline
> > > functions instead. :-)
> >
> > The intended use of those macros was for the implementation of the Mercury
> > system itself.  They aren't inline C function because in that role
> > it's probably not
> > useful for them to be inline C functions.  (To say nothing of the fact
> > that when those
> > macros were originally written, C did not have a standard notion of an inline
> > function.)
>
> Okay
>
> > The secondary role of these macros as a mechanism by which users can
> > manipulate lists in foreign code has arisen, more or less, by accident.
>
> But it's documented in the "C data passing conventions" section. So it's no
> accident when users want to use them...

I didn't say it was an accident that users want to use them, it was
the fact that
they *are* the documented mechanism that I was referring to as an accident.

> > > This leads to the second best solution: Wrap those macros in inline
> > > functions. And instruct the user to use them instead of the macros. For
> > > instance, like this:
> > >
> > > static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail)
> > > {
> > >    MR_Word result = MR_list_cons(head, tail);
> > >    return result;
> > > }
> > >
> > > This should amend the problem. Or am I missing something? It seems odd to me
> > > that this obvious solution hasn't been implemented already.
> >
> > My suggestion would be that the list module in the standard library
> > provide function
> > versions of these operations (as indeed it does for the C# and Java backends).
> > Users should be directed to those, instead of the runtime macros ...
>
> Yes, that's what I have in mind. Although it applies only to those five list
> processing macros.

Yes, they are all that the C# and Java backends provide.  We are limited in
which list processing operations can be supported in this way by how
polymorphism
is handled.  (Essentially, you can only do it like this for operations
where the type_info
is not required.)

> > ... or users should just foreign export pragmas the operations they
> > need to manipulate
> > lists in foreign code.  As indeed you would need to do if you wanted
> > to manipulate just
> > about any other data structure in the Mercury standard library from
> > foreign code.  This
> > approach also automatically handles whether arguments need to be boxed etc.
>
> Since you say so, I assume this is efficient.

The macros are faster than exported Mercury procedures, but that is not the same
as saying the latter are not efficient.  I think for most
non-contrived use cases the
differences between them won't matter.

> Having those list macros, or function equivalences of them, sure is handy.

There are trade-offs:

Foreign exporting the operations means you can ignore a lot of
implementation details like
boxing of certain argument types, what the MR_hp register is doing etc.

OTOH, the advantage of the list operations provided is that while they
are polymorphic,
you don't need to deal with that.  (Pragma foreign_export'ing
polymorphic predicates is possible,
but it's generally easier not to deal with all that.)

Julien.