[m-users.] Mercury macro trouble

[Mark Brown]

On Tue, Jun 4, 2024 at 6:33 PM Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Dienstag, dem 04.06.2024 um 10:50 +1000 schrieb Mark Brown:
> > On Mon, Jun 3, 2024 at 8:03 PM Volker Wysk <post at volker-wysk.de> wrote:
> > > the documentation
> > > should be extended by a sentence or two. Saying that the macro versions are
> > > problematic and that users should use foreign exports instead - or that they
> > > should use inline functions, which wrap the macros, like it was discussed.
> >
> > Adding qualifiers about all of C's relevant quirks would not improve
> > our documentation in my view. The issue with macros is something I was
> > taught early on when learning C, and I think it inherently applies to
> > macros for any language with imperative features. It should be enough
> > just to say that they are macros.
>
> Why can't you (the Mercury team) just replace those five macros with inline
> function versions with the same name? This would resolve all those quirks
> and issues...

I wasn't saying anything about that proposal, only that Mercury
documentation isn't the right place to look for details about C.

My own experience with the foreign interface is that it is way harder
to robustly build Mercury data structures in C than it is to define an
interface that accesses data in a C-like fashion. For example, if the
C code is producing something that would typically be stored in a C
array, then have the Mercury interface be able to read its size and
access it by index. If you want the results as a Mercury list, you can
then write Mercury code that iterates over the indices and constructs
one. Obviously there's some costs there, but they would be similar to
the costs normally associated with using Mercury lists rather than
Mercury arrays.

If the C data structure really is a singly-linked list, then have the
Mercury interface provide a test for whether there is a next element,
and a function to return it. You can then write semidet Mercury code
to get the next value if it exists, or use Mercury to construct a
'maybe' value. (Naturally, the low-level function to return the next
value would be unsafe unless the test is performed first, but that's
non-Mercury code for you.)

Note that this style of interface also works for doubly-linked lists
and other cyclic data structures in C, and has the advantage that you
can't accidentally build a Mercury term like that.

Cheers,
Mark

>
> Cheers,
> Volker
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users