[m-dev.] for review: handle `:- external' in MLDS back-end

[Fergus Henderson]

On 11-Dec-2000, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 10-Dec-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > +++ compiler/hlds_pred.m	2000/12/09 10:41:16
> > @@ -258,9 +258,11 @@
> >  	% Only types can have status abstract_exported or abstract_imported.
> >  
> >  :- type import_status
> > -	--->	imported(section)
> > +	--->	external(section)
> > +				% declared `external',
> > +				% i.e. defined in some other language
> > +	;	imported(section)
> >  				% defined in the interface of some other module
> > -				% or `external' (in some other language)
> >  	;	opt_imported	% defined in the optimization
> >  				% interface of another module
> >  	;	abstract_imported % describes a type with only an abstract
> 
> IMO external doesn't really mean defined in some other language.
> 
> It means an implementation for this predicate/function will be provided
> by an external source (and specifically, not through Mercury clauses).
> 
> This could be through the use of another language, or it could be
> through automatic generation by the compiler, or some other method we
> haven't thought of yet.

Agreed.  I'll update the comments there accordingly.

--- hlds_pred.m.old	Mon Dec 11 15:22:13 2000
+++ hlds_pred.m	Mon Dec 11 15:28:35 2000
@@ -259,8 +259,15 @@
 
 :- type import_status
 	--->	external(section)
-				% declared `external',
-				% i.e. defined in some other language
+				% Declared `:- external'.
+				% This means that the implementation
+				% for this procedure will be provided
+				% by some external source, rather than
+				% via Mercury clauses (including
+				% `pragma foreign_code' clauses).
+				% It can be through the use of another
+				% language, or it could be through some
+				% other method we haven't thought of yet.
 	;	imported(section)
 				% defined in the interface of some other module
 	;	opt_imported	% defined in the optimization

> FYI: I plan to make MLDS -> IL turn it into a forwarding call (much like
> it does for pragma foreign_code("MC++", somepred(....), ...)).  So you
> can provide an implementation by writing a static method (with the right
> mangling) in Managed C++. 
> 
> This will solve the problem at the moment, where :- external doesn't
> work because there is no forwarding call generated from
> `modulename.predname' to `modulename__c_code.predname'.

Sounds great.

> > +		% XXX FIXME wrap long lines
> 
> Should this still be here?

No, the comment there was just a reminder to myself
which I had acted on but forgotten to delete.
I'll delete it.

> This appears to be just re-formatting -- it should be mentioned in the
> log message.

As part of the changes described in the log message, I had to move a
large chunk of code into the body of an if-then-else; this required
indenting the code one extra tab, and then wrapping the lines which
didn't fit in 80 columns any more.  My diff didn't include any
reformatting other than this, which was required to make the change
described in the log message (in a way that abides by our coding
guidelines).

> You could also fix the error messages in make_hlds. 

I'll do that one as a separate change.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  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
--------------------------------------------------------------------------