[m-rev.] for review: implement solutions on the IL backend

[Fergus Henderson]

On 06-Aug-2001, Tyson Dowd <trd at miscrit.be> wrote:
> On 05-Aug-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > Pete, you seem to have ignored these review comments and committed your
> > code anyway.
> > 
> > This is really not acceptable.
> > Please address the review comments ASAP or back out your change.
> 
> Pete doesn't have the time to fix this at the moment, so I will do it.

OK, thanks Tyson.

> > On 15-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > On 14-Jul-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > > +			type_util__var(Type, _),
> > > > +			Target = il
> > > > +		->
> > > > +			TypeString = "MR_Box"
> > > > +		;
> > > > +			export__type_to_type_string(Type, TypeString)
> > > > +		),
> > > 
> > > I think "Target = il" is not the right test here, or at least not the best test.
> > > This is really a property of the foreign language interface, rather than of
> > > the target language, so you should be switching on
> > > `Lang = managedcplusplus' rather than `Target = il',
> > > where `Lang' is obtained via `foreign_language(Attributes, Lang)'
> > > (you'll need to pass it down to ml_gen_pragma_c_decl).
> > > 
> > > This difference between the C interface and the MC++ interface really
> > > ought to be documented.  Unfortunately the MC++ foreign code interface
> > > is not documented at all, so for now I just suggest you put something
> > > commented out (with @c) in doc/reference_manual.texi, e.g. see patch below.
> 
> The MC++ interface really needs to be fixed so that it doesn't rely on
> the C foreign language interfacing at all.  This is a medium size job
> that I don't have time to do just yet.

Actually I've already addressed that one myself, to the level that I
requested in the review comment, by putting the appropriate @c comments
in doc/reference_manual.texi.

> One piece of documentation that really should be known to you is that
> functions don't work in Managed C++.

Ouch.  Why not?

> > > It might even be better in the long run to
> > > do this inside export__type_to_type_string itself (i.e. to make the
> > > foreign_language a parameter to that routine), but that can probably
> > > wait for another day.
> 
> I think the export code is best left to just handling C code -- we
> re-use far too much of it for MC++ as it is.  It would be much easier to
> maintain if we just implement MC++ the same way as C# (Task 34698).

Well... I agree on some points but not entirely.

Eventually we will want to support `pragma export' or equivalent for the
.NET and Java back-ends, and at that point the export code is going to
need to be generalized somehow.

I agree that MC++ should be implemented using outline_foreign_proc.

However, I just noticed that the way the C# foreign interface is
implemented means that the types of the parameters depends on the grade.
That means that in general it impossible to write C# foreign code that
is portable between different grades of the Mercury compiler, and has
parameters of user-defined Mercury types with both "in" and "out" modes.
"in" mode parameters are OK, since you can just assume they are of type
"object", and C# will handle any conversions automatically.
But "out" mode parameters don't work, since the type to cast back to
depends on the grade.

This aspect of the C# foreign interface should be changed.
It should not be emulated for the MC++ interface.

Note that if the C# foreign interface had been documented,
this issue probably would have come up when writing or reviewing
the documentation.

> Here is the diff addressing your concerns.  I am testing it now.

The diff looks good.  Thanks.

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