[m-rev.] for review: end-user documentation for Erlang backend

[Peter Wang]

On 2007-07-18, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
> 
>  On Wed, 18 Jul 2007, Peter Wang wrote:
> 
> > +You can pass the `--erlang-native-code' option to mmc to use HiPE to 
> > compile
> > +.erl files to .beam files.  It is recommended to add this flag to
> > +Mmake.params before installing the standard library.
> > +
> > +The need to support user-defined equality and comparison predicates can
> > +cause significant slowdowns, even when they are unused.  This problem
> > +usually exists when a type contains an abstract type in its definition.  
> > The
> > +compiler does not know if an abstract type has user-defined equality or 
> > not,
> > +so makes a conservative assumption.  Enabling intermodule optimisation 
> > gives
> 
>  	... so it makes a conservative ...
> 
> > +the compiler enough information to avoid this problem.
> 
>  I wouldn't have thought so.
> 

I've changed that to "gives the compiler _more_ information to avoid
this problem", i.e. doesn't solve it completely.  I built one compiler
with -O5 --intermodule-optimisation and compared it with another
built at -O2 which didn't try to support user-defined equality.
They were roughly equally fast.  I will test the latter one at -O5
--intermod-opt some time.

> > + at node Erlang data passing conventions
> > + at subsection Erlang data passing conventions
> > +
> > +The Mercury types @code{int}, @code{float} and @code{char}
> > +are mapped to Erlang integers, floats and integers respectively.
> > +A Mercury @code{string} is represented as a list of integers in Erlang.
> > +
> > +Mercury variables whose type is a Mercury discriminated union type
> > +will be passed as an Erlang tuple with the first element of the tuple
> > +being an Erlang atom named after the Mercury data constructor.
> 
>  I suggest adding an example of how a du type is represented in Erlang
>  here.
> 

+For example, values of the type:
+
+ at example
+    :- type maybe_int
+        --->    yes(int)
+        ;       no.
+ at end example
+
+ at noindent
+would be represented in Erlang as @samp{@{yes, @var{integer}@}} and
+ at samp{@{no@}}.

> > + at c XXX currently foreign_exported procedures won't be visible outside
> > + at c the defining module.
> 
>  If that restriction is still current then I think it user's ought
>  to be aware of it.
> 

Changed to:

+(Currently foreign_exported procedures won't be visible outside
+the defining module.  This should be fixed soon.)

> > @samp{.profdeep})
> > @findex --deep-profiling
> > @cindex Deep profiling
> > Enable deep profiling by inserting the appropriate hooks in the generated 
> > code.
> > -This option is not supported for the high-level C, IL and Java back-ends.
> > +This option is not supported for the high-level C, IL, Java and Erlang
> > +back-ends.
> 
>  It would be simpler to say:
> 
>  	This option is only supported by the low-level C back-end.
> 
>  rather than listing everything that doesn't support it.
>  Likewise, some of the above should just say "This option is only
>  supported by the C back-ends,"

Fixed.

> > Index: scripts/Mercury.config.in
> > ===================================================================
> > RCS file: 
> > /home/mercury/mercury1/repository/mercury/scripts/Mercury.config.in,v
> > retrieving revision 1.17
> > diff -u -r1.17 Mercury.config.in
> > --- scripts/Mercury.config.in	15 Nov 2006 08:12:56 -0000	1.17
> > +++ scripts/Mercury.config.in	18 Jul 2007 02:37:34 -0000
> > @@ -27,6 +27,8 @@
> > MERCURY_JAVA_COMPILER=@JAVAC@
> > MERCURY_JAVA_INTERPRETER=@JAVA_INTERPRETER@
> > MERCURY_CSHARP_COMPILER=@MS_CSC@
> > +MERCURY_ERLANG_COMPILER=@ERLC@
> > +MERCURY_ERLANG_INTERPRETER=@ERL@
> > # $(MATH_LIB) needs to be defined because it may
> > # be used by the substitution for SHARED_LIBS.
> > MATH_LIB=$(MERCURY_MATH_LIB)
> > @@ -52,6 +54,8 @@
> > 		--java-compiler "$(MERCURY_JAVA_COMPILER)" \
> > 		--java-interpreter "$(MERCURY_JAVA_INTERPRETER)" \
> > 		--csharp-compiler "$(MERCURY_CSHARP_COMPILER)" \
> > +		--erlang-compiler "$(MERCURY_ERLANG_COMPILER)" \
> > +		--erlang-interpreter "$(MERCURY_ERLANG_INTERPRETER)" \
> > 		--cflags-for-ansi "@CFLAGS_FOR_ANSI@" \
> > 		--cflags-for-optimization "@CFLAGS_FOR_OPT@" \
> > 		--cflags-for-warnings "@CFLAGS_FOR_WARNINGS@" \
> 
>  Do you also need to update Mercury.config.bootstrap.in?
>

I don't think so.  That would only affect people trying to build the
stage 1 compiler to Erlang.  I haven't even tried to do that using the
build system directly, and some more library procedures are required.

I followed your other suggestions.

Peter
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------