[m-dev.] multi-language definitions

Zoltan Somogyi zs at cs.mu.OZ.AU
Sat Feb 23 15:15:57 AEDT 2002


On 23-Feb-2002, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Fri, Feb 22, 2002 at 07:02:28PM +1100, Zoltan Somogyi wrote:
> > Is that a distinction that is important in practice? Surely we should
> > encourage people to provide definitions of their predicates that will work
> > for all back ends (even if on some back ends, they only call "sorry"),
> > which means that all predicates that have no Mercury clauses *should*
> > have multiple foreign_procs.
> 
> Doesn't that mean that existing, working Mercury code will stop
> compiling when a new compiler is released that has new back ends?
> That doesn't seem desirable.

It is not desirable in general, though it would be useful for us; at present
we have no automatic method that tells us which library predicates still
haven't been implemented for a given back end.

However, my proposal does *not* mean that existing, working Mercury code
will stop compiling when a new compiler is released that has new back ends,
because nowhere did I propose that the compiler check that the list of
foreign_proc implementations of a procedure covers all the back ends.
I merely said that implementors should strive towards this objective.

Here is what happens with my proposal when you add a new back end:

- If a procedure is defined only in Mercury clauses: no change.

- If a procedure is defined both in Mercury clauses and foreign_procs:
  the Mercury clauses will apply for the new back end.

- If a procedure is defined only in foreign_procs: each old back end will
  treat the procedure exactly as before, while the new back end will raise
  an error. Alternatively, we could make the new back end follow Holger's
  suggestion and assume that the procedure is defined somewhere else.

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



More information about the developers mailing list