[m-users.] Generating Mercury with Claude AI (was Re: users Digest, Vol 125, Issue 2)

[Mark Brown]

Hi Ted,

I think that tips and observations on generating Mercury using AI
tools is on-topic for this list. In any case I would like to hear
about your experiences :-)

On Sun, Oct 26, 2025 at 9:41 PM Ted Stock <testock at gmail.com> wrote:
>
> Hi Tomas,
>
> Feel free to reach out to me directly if you’d prefer not to fill the list with AI discussion, but here are a few notes from my experience.
>
> I used Claude to build a Python-style regular expression module with a C PCRE2 backend. I was pleasantly surprised by Claude’s clauses (sorry). The whole process took about three hours, including some light testing. Claude did wander down a few blind alleys and needed occasional redirection, but given my rusty C skills, it still saved me close to a week of work. For those interested, the (currently unpolished) repository is here: https://github.com/testock/mercury-re
>
> A few tips:
>
> 1. When working with Claude and Mercury, make sure it has access to the compiler source. This lets you point it to relevant examples it can use to model its output.

I found that Claude Pro didn't need this. It understood Mercury
out-of-the-box, though it was not able to install Mercury itself. The
paid subscription lets you run claude locally, where it can run your
own installed Mercury (by default it asks for confirmation before
executing anything).

The integration was too easy. For example, I just needed to say, "You
can compile Mercury modules using 'mmc --make foo.c'" and now it does
that without prompting.

>
> 2. Claude doesn’t always interpret compiler errors correctly, so you’ll need to keep an eye out for cases where it gets “confused.”

I found it didn't understand even basic error messages at first, but
learned quickly. For example, I think I said something like, "You need
to import the int module for integer operations. The float module only
provides floating point operations", and since then it has fixed
similar errors on its own, such as needing 'list' when list syntax is
used, or needing 'string' when 'io.format' is used.

It also appeared to understand why try/catch goals require code to be
declared 'cc_multi', including callers, after I had told it to make
the change on one occasion. Here is its response to the query "Do you
understand why the determinism needed to be changed?":

  Yes, I understand why the determinism needed to be changed to cc_multi.

  In Mercury:
  - det (deterministic) means a predicate succeeds exactly once with no
  choice points
  - cc_multi (committed choice multi) means a predicate can have multiple
  solutions internally, but commits to the first one found

  The try/catch exception handling mechanism has cc_multi determinism
  because:

  1. Multiple potential execution paths exist: The code inside the try block
   might succeed normally, or an exception might be thrown and caught
  2. Mercury commits to one path: Once execution enters either the success
  branch or the exception handler, it commits to that path and doesn't
  backtrack
  3. No backtracking over I/O: Since the predicates have I/O state
  arguments, they can't be fully non-deterministic anyway (you can't
  duplicate or destroy I/O state)

  Because test_extremum uses try/catch (which is cc_multi), it must be
  declared cc_multi. And because main calls test_extremum (via list.foldl),
  it also needs to be cc_multi - the determinism "propagates up" the call
  chain.

  The "cc" (committed choice) part is important here: even though there are
  conceptually multiple paths through the code, Mercury commits to whichever
   path is taken and doesn't allow backtracking over the exception handling.

Pretty neat I'd say. If I explained the words "declarative" and
"operational" it might give an even more pertinent response. Suffice
to say, I'm very interested to find out how far it can go.

>
> Overall, I found Claude quite helpful for the more tedious parts of writing Mercury-C wrappers, though I haven’t used it for more substantial Mercury development. I suspect AI assistants will prove particularly effective for Hindley-Milner languages like Mercury, where strong typing and compiler guarantees reduce the need for extensive code review. My use case doesn’t benefit from that as much, since interfacing with C is inherently less type-safe.

I found that while it really can't analyse problems well enough to
program on its own in the general case, you can describe your analysis
to it and it picks things up pretty well. In fact it can find
inconsistencies and other errors in your own understanding of the
problem, which is possibly its strongest and most overlooked feature.

Whatever misgivings one may have about the quality of the generated
code, it can still be used for some very, very rapid prototyping.

Cheers,
Mark

>
> Best regards,
> Ted
>
>
>
> On Oct 26, 2025, at 02:00, users-request at lists.mercurylang.org wrote:
>
> Send users mailing list submissions to
> users at lists.mercurylang.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.mercurylang.org/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-request at lists.mercurylang.org
>
> You can reach the person managing the list at
> users-owner at lists.mercurylang.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>   1. (cough) "AI" (Tomas By)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 25 Oct 2025 22:31:47 +0200
> From: Tomas By <tomas at basun.net>
> To: Mercury Users <users at lists.mercurylang.org>
> Subject: [m-users.] (cough) "AI"
> Message-ID: <878qgy4tak.wl-tomas at basun.net>
> Content-Type: text/plain; charset=US-ASCII
>
> Hi all,
>
> Just read this on Slashdot:
>
> | I'm a programmer who started out hesitant about AI, and at first I
> | thought all that it could do was auto-complete better.
> | Then I tried Claude Code, and it really is like having your own
> | personal junior dev assisting you're every need. Like a junior, it
> | makes mistakes, but using the *massive* amount of good code that it
> | creates, and fixing what's left, is so much faster than writing it
> | all from scratch yourself.
> https://slashdot.org/story/25/10/25/0324244/meet-the-people-who-dare-to-say-no-to-ai
>
> and wonder if anybody has tried this with Mercury?
>
> I suspect that (1) this person uses C[*]/Java, and (2) the usefulness
> of this "AI" stuff for Mercury will be proportionally less in a
> similar magnitude as code length for same functionality, ie a factor
> ten or so.
>
> Anybody has any experiences?
>
> /Tomas
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
>
>
> ------------------------------
>
> End of users Digest, Vol 125, Issue 2
> *************************************
>
>
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users