[m-rev.] for review: mix mercury code with foreign_proc

[Fergus Henderson]

On 30-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> compiler/make_hlds.m:
> 	Set the goal type for potentially mixed mercury/foreign_proc
> 	clauses as "clauses".

I don't think that is a good idea.  It would be much better to add a new goal
type clauses_and_pragmas and set it to that.  Some places in our existing code
assume that `clauses' means that there are no pragmas.

You'll also need to go through and find all the places in the compiler
that use `pragmas' or `clauses' and see if they need to be updated to
check for `pragmas_and_clauses'.  I had a brief look and there is at
least one place that needs to be updated.

Those two points should be addressed before you commit this.

> compiler/hlds_pred.m:
> 	Add a field to clauses_info to record whether we have any
> 	foreign_proc clauses.

It would be nice to use record syntax for the clauses_info.

Ideally we ought to perform semantic analysis on Mercury clauses
even if they are overridden by foreign language pragmas.
Your patch doesn't do that.  However, that can remain a wishlist item
for some future patch...

> +				PreferNewLang = 
> +					foreign__prefer_foreign_language(
> +						Globals, Target, OldLang,
> +						NewLang),
> +					% This language is preferred to the old
> +					% language, so we should replace it
> +				( PreferNewLang = yes ->

The comment should go after the `PreferNewLang = yes' test, not

It might be simpler to just omit the PreferNewLang variable entirely,
and just write the call to prefer_foreign_language inside the condition
of the if-then-else.

> +					Action = replace(N0)
> +				;
> +					% Just ignore it.
> +					Action = ignore
> +				)
> +			;
> +				Action = Action0
> +			),
> +			N = N0 + 1
> +		), ClauseList, add, FinalAction, 1, _) },
> +
> +	{ UpdateClauses = (pred(NewCl::in, Cs::out) is det :-
> +		( FinalAction = ignore,
> +			Cs = ClauseList
> +		; FinalAction = add,
> +			Cs = [NewCl|ClauseList]
> +		; FinalAction = replace(X),
> +			list__replace_nth_det(ClauseList, X, NewCl, Cs)
> +		; FinalAction = split_add(X, Clause),
> +			list__replace_nth_det(ClauseList, X, Clause, Cs1),
> +			Cs = [NewCl|Cs1]

s/|/ | /

> Index: doc/reference_manual.texi
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
> retrieving revision 1.212
> diff -u -r1.212 reference_manual.texi
> --- doc/reference_manual.texi	2001/07/25 15:49:53	1.212
> +++ doc/reference_manual.texi	2001/07/30 15:09:26
> @@ -4785,6 +4785,13 @@
>  (If you use this form, and the C code @emph{does} invoke Mercury code,
>  then the behaviour is undefined --- your program may misbehave or crash.)
>  
> +It is possible to provide both a Mercury definition, and
> +a foreign_proc definition for a procedure.

"a" foreign_proc definition?  Just one?  I thought the idea was to permit
multiple such definitions, so long as they are for different languages.
The wording needs to make that clear.

> +All such Mercury definitions must use mode-specific clauses (even if
> +there is only a single mode for the predicate).
> +Suitable foreign_proc definitions will be used first, but
> +if no suitable foreign_proc definition is found, the Mercury definition
> +will be used instead.

That's a bit imprecise.  What's "suitable"?
And what does "used first" mean? 
Is that a constraint on the order of execution? ;-)

How about just saying that if there are both Mercury clauses and foreign_proc
definitions, it is implementation-defined which definition used?

We also need to say somewhere that for pure and semipure procedures the
declarative semantics of the foreign_proc definition(s) must be the same as
that of the Mercury code.  The only thing that is allowed to differ is the
efficiency (including the possiblity of nondetermination), and the order of
solutions.

> Index: doc/user_guide.texi
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/doc/user_guide.texi,v
> retrieving revision 1.265
> diff -u -r1.265 user_guide.texi
> --- doc/user_guide.texi	2001/07/25 14:13:35	1.265
> +++ doc/user_guide.texi	2001/07/30 15:09:30
> @@ -5697,6 +5697,16 @@
>  @node Foreign language interface
>  @chapter Foreign language interface
>  
> +If the compiler generates code for a particular target for which 
> +there are multiple applicable foreign languages, it will choose the
> +foreign languages according to a builtin ordering. 

I know what you mean by this, but I fear that many readers wouldn't.
Please explain in more detail.  You need to mention `pragma foreign_proc' here,
otherwise people won't know what you are talking about.

> +If the language is not available for a particular backend, it will be
> +ignored. 

Likewise.

> +Mercury clauses will be used if there are no suitable foreign_proc
> +clauses for a particular procedure.

Ah, I see you do mention foreign_proc eventually, but a bit too late IMHO.

-- 
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-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------