[m-dev.] multi-language definitions

[Zoltan Somogyi]

At the moment, we are using mode-specific clauses not just for mode-specific
code but also to tell the compiler that it should use the Mercury code only if
there is no foreign_proc definition appropriate for the current back end.

Apart from being inelegant, this arrangement has the drawbacks that one cannot
have both foreign_proc and Mercury definitions for zero-arity predicates,
and that the fallback Mercury code must have mode specific clauses even if this
is not natural.

I propose that we add a new pragma that names a predicate or function
and tells the Mercury compiler that the Mercury definition of that predicate
or function is just a fallback in case the predicate or function has no
foreign_proc definition appropriate for the current back end. This pragma
could be called something like "foreign_and_mercury". Another pragma,
called something like "foreign_only", would say that the predicate or function
has only foreign_proc definitions.

The rules would be:

- If a predicate or function only has Mercury clauses, then it must not have
  either a foreign_and_mercury pragma or a foreign_only pragma.

- If a predicate or function has both Mercury clauses, and foreign_procs,
  then it must have a foreign_and_mercury pragma and must not have a
  foreign_only pragma.

- If a predicate or function has only foreign_procs, then it must have a
  foreign_only pragma and must not have a foreign_and_mercury pragma.

The compiler would enforce these rules, but would cease taking mode-specific
clauses as being only a fallback in the absence of an appropriate
foreign_proc for the predicate or function in question.

Both new pragmas would serve as a promise by the programmer that the different
definitions have the same semantics.

The foreign_and_mercury pragma could have an argument that is a list of
languages, just like the languages in the first arguments of foreign_procs,
that gives the list of languages for which the Mercury implementation is
appropriate. The compiler could give an error if the current back end's
language is not listed either there or in a foreign_proc for a predicate
or function.

The proposed arrangement would solve both problems above, and is reasonably
likely to catch errors, both the omission of needed back end specific
definitions and their unnecessary provision.

By the way, we need a way of identifying predicates and functions in
declarations that can unambiguously distinguish between

:- pred x(x::in) is semidet.

and

:- func x(int) = int.

This affects other declarations as well, e.g. the ones for fact tables
and :- external, so it is a separate discussion.

Comments?

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------