[m-dev.] diff: additions to samples/c_interface

Simon TAYLOR stayl at students.cs.mu.oz.au
Fri Jul 25 09:50:10 AEST 1997


Hi Fergus,


> doc/reference_manual.texi:
> 	Document `pragma export'.
> 	Also various minor corrections.
> 

Just a few minor nits here.

> -The University of Melbourne Mercury implementation will offer eight
> +The University of Melbourne Mercury implementation offers eight
>  different semantics, which will be selected with different

s/will be/are/

>  combinations of the @samp{--no-reorder-conj}, @samp{--no-reorder-disj},
>  and @samp{--fully-strict} options.  (The @samp{--fully-strict} option
> -will prevent
> -the compiler from improving completeness by optimizing away infinite
> +prevents the compiler from improving completeness by optimizing away infinite
>  loops or calls to @code{error/1}.)  The default semantics will be the
>  commutative semantics.  Enabling all of these options will give you the

s/default semantics will be/default semantics is/
s/will give you/gives you/

> +SUCCESS_INDICATOR should not be used other as the target of an assignment.

should not be used other _than_ as 

> +
> +A declaration of one the form
> +
> + at example
> +:- pragma export(@var{Pred}(@var{Mode1}, @var{Mode2}, ...), "@var{C_Name_1}").

s/one //

> +Calling polymorphically typed Mercury procedures from C is a little bit
> +more difficult than calling ordinary (monomorphic) Mercury procedures.

more difficult than calling monomorphically typed Mercury procedures. ?

>  
> +A Mercury implementation should allow you to link with 
> +The exact mechanism for linking with C object files is
> +implementation-dependent.  The following text describes how
> +it is done for the University of Melbourne Mercury implementation.

Remove the first line here.

Simon.



More information about the developers mailing list