[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