[m-dev.] multi-language definitions

[Fergus Henderson]

On 22-Feb-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 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.

Well, not really.  It's just that we currently don't support the
combination of non-mode-specific Mercury code with foreign_proc
definitions.  And the only reason that we don't currently support that
is that it was non-trivial to implement.  I plan to eliminate this
restriction.

In the general case, each procedure may be defined in several
languages (possibly including Mercury), and each back-end may
support several languages; for each back-end, there will be an
order of preference for the different languages.
(In some rare cases, it might be desirable to override the
default order of preference for a particular procedure.
So we may need some language extension to support that.
However, I think the need for this is likely to be very rare
in practice and we can cross that bridge when we get to it.)

The only reason that Mercury clauses are special in this respect
is that they are the only language which is guaranteed to be supported
by all back-ends.

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

Why?  The compiler can easily see whether there are clauses for both
Mercury and other languages, or just for Mercury.
What's the advantage in the programmer saying the same thing twice here?

I understand the idea of adding redundancy for error-checking,
but I don't really see what kind of errors you are trying to catch
here.  For example, if the programmer accidentally misspells the
name of the predicate in either the clauses or the foreign_procs,
then they'll already get an error.  If the programmer has explicitly
written both Mercury and foreign_proc declarations for a predicate,
it seems extremely unlikely that they would have done so by accident,
and so I don't see the point in making them write an additional pragma
to say "I really meant to define both".

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

This goes against our existing practice of having all unchecked promises
contain the word "promise" somewhere in them.

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

You are assuming that each back-end will only support a single foreign
language.  This assumption is not correct.

In addition, I find it hard to imagine a situation in which the
Mercury clauses would be specific to a particular back-end.
In the vast majority of cases, either (a) the Mercury clauses
will work for any back-end, or (b) the Mercury clauses just call
error/1.  Either way, I don't see that advantage of explicitly listing
which back-ends it should be used for.

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

In case (a) the omission of a back-end-specific definition is not an error.
In case (b) the programmer has explicitly indicated that they don't
want it to be a compile-time error if there is no suitable foreign_proc
definition (as may be appropriate if the functionality is unlikely to
be exercised).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------