[m-users.] Mercury macro trouble

[Volker Wysk]

Am Dienstag, dem 04.06.2024 um 21:39 +1000 schrieb 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.

I was thinking about something like "Please be aware that C macros are
problematic. Use the function versions instead."

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

That's some useful information. Please consider adding it to the Language
Reference Manual.

Regards,
Volker