[mercury-users] C Interface (was Circular lists)

[Andrew Bromage]

G'day.

Tyson Dowd wrote:

> It sounds like you'll be pretty much restricted to checking what
> could be called "pure C". But "pure C" doesn't let you do anything you
> can't do in Mercury anyway.

I can think of one compromise.

Many lazy functional languages are implemented using at least four
"intermediate" forms:

	- The abstract syntax tree,
	- a high-level description usually resembling lambda calculus,
	- a medium-level abstract assembly language (e.g. G code
	  or ABC code), and
	- the low-level output language (e.g. C or assembly language).
	
Mercury does not use separate medium-level and low-level languages.  Our
LLDS is sort of half-way between them.  (It's too low-level to run, say,
termination analysis, but it's low enough that it can be easily and
efficiently implemented using C macros.)

If we did, we could allow people to write code in that medium-level
language (like Clean does).  This way, we could get an appropriate
set of static analyses plus some degree of low-level control.

It wouldn't help for situations such as...

> I/O, networking, IPC, graphics, pointer-manipulation, etc. 

but it might help for arrays and stores, and would certainly help for
hacks like setarg.

There is always the possibility of designing and implementing a
suitable medium-level language with the appropriate features and
analyses which is not used in the normal compilation process and
compiles to LLDS.  Perhaps Richard O'Keefe would be a bit happier
with this kind of tool.

Disclaimer: No, I am not volunteering to write this, and my (educated)
guess is neither would any of the rest of the Mercury team.  From our
point of view, it's not at all worth the time we'd spend on it, since
we'd spend more time debugging the medium-level language compiler than
we do debugging our (usually very) small fragments of C code.

Cheers,
Andrew Bromage

P.S.  Mercury bytecode isn't suitable for this purpose, so don't
start bugging Bert. :-)