[m-users.] Mercury macro trouble

[Volker Wysk]

Am Dienstag, dem 28.05.2024 um 08:57 +1000 schrieb 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.

That was just a little rhetoric for my part.

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

I'm agreeing to your suggestion of providing (inline) function versions of
those five macros. This would avoid the painful experiences which M.
McDonough had.

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

Okay

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

Hmm. Sounds more involved than I was aware. Good thing that the details can
be ignored when using foreign exports.

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

Same here.

Cheers,
Volker