[m-rev.] for review: update docs for foreign language interface

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Nov 1 00:19:28 AEDT 2002


On 31-Oct-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> On Thu, Oct 31, 2002 at 10:38:42PM +1100, Fergus Henderson wrote:
> > On 31-Oct-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> > > I would a line saying that the MC++ interface is only recommended for
> > > use when C# or the IL interface can't be used as it is by far the most
> > > brittle interface.
> > 
> > In what sense is the MC++ interface "brittle"?
>
> It is brittle in the sense that both Tyson and I hate using it.  Things
> go wrong all the time

More often than for the C# or IL interfaces?  Why?

> and when they do the error message you get out of
> the MC++ compiler is quite often incomprehensible.

So the language reference manual should recommend against using the MC++
interface because MSVC gives poor error messages?

I don't know, to me that just doesn't seem like an appropriate thing to
put in the Mercury language reference manual.

> > I'm not going to advise people to use the IL interface rather than the
> > MC++ interface, because the MC++ interface is much higher-level than
> > the IL interface.
> > 
> > I could put in some advice recommending the use of the C# interface in
> > preference to the MC++ interface on the grounds that it is more portable,
> > I suppose.
>
> I do think a piece of advice along the lines of: this can be the most
> difficult interface of the three interfaces to use, so only use it if
> you really need to.

AFAIK it shouldn't be any harder to use than the C# or IL interfaces,
except in that MC++ might be a more complicated language and/or might
have a worse compiler.  But those are the usual issues when choosing a
language.  I think people reading the Mercury language reference manual
should be capable of making reasonable decisions about which of the
three languages is appropriate for a given task without needing such
advice.

Here's the relative diff to address your other comment.

--- reference_manual.texi.old	Fri Nov  1 00:02:56 2002
+++ reference_manual.texi	Fri Nov  1 00:02:58 2002
@@ -5442,8 +5442,10 @@
 For output arguments,
 the Mercury implementation will pass to the IL or C# function a reference to
 the location in which to store the result; for example, a Mercury output
-argument of type @samp{int} would map to a C# function parameter with type
- at samp{ref int}.
+argument of type @samp{int} would map to a C# @samp{ref int}
+function parameter.  (Note that we map to @samp{ref int}, not @samp{out int};
+for procedures that can fail, output arguments only need to be set if the
+procedure succeeds.)
 If the Mercury procedure can fail,
 then its IL or C# function should return a truth value of type
 @samp{bool} (i.e.@: @samp{System.Bool}) indicating success or failure:
-- 
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
--------------------------------------------------------------------------



More information about the reviews mailing list