[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