[m-rev.] for review: data passing convention documentation

[Fergus Henderson]

On 06-Dec-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> On Thu, Dec 06, 2001 at 07:24:03PM +1100, Fergus Henderson wrote:
> > On 03-Dec-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > +The Mercury types @code{int}, @code{float}, @code{char},
> > > +and @code{string} are mapped to the Common Language Runtime types 
> > > + at code{System.Int32}, @code{System.Double}, @code{System.Char} and
> > > + at code{System.String} respectively.
> > > +
> > > +Mercury variables which are polymorphically typed (e.g. whose type is a 
> > > +type variables) will be passed as @code{System.Object} while all other
> > > +Mercury variables are passed as @code{System.Object[]}.

This statement is wrong: a variable whose type is `list(T)' is
"polymorphically typed", yet it will be passed as `System.Object[]',
not `System.Object'.

> > > +This mapping is subject to change and you should try to avoid writing
> > > +code that relies heavily upon a particular representation of Mercury
> > > +terms.
> > 
> > The documentation here should explain both the --high-level-data
> > and --no-high-level-data case, rather than assuming --no-high-level-data.
>
> Since you designed and implemented the high-level-data representation, I
> would suggest that you are better placed to document it than me.

For the high level data representation,
Mercury variables whose type is a Mercury discriminated union type
will be passed as a CLR type whose type name is determined from
the Mercury type name (ignoring any type parameters) followed by
an underscore and then the type arity, expressed as a decimal integer.
Mercury module qualifiers are converted to CLR namespace qualifiers.
For example the Mercury type `foo__bar__baz/1' will be passed
as the CLR type `foo.bar.baz_1'.

> BTW does it even work yet?

For the C back-end, `--high-level-data' works fine (though there
are some issues with installation: currently we only install
one copy of the header files, so you can't install both hlc.gc
and hl.gc and have them both work at the same time).

For the IL back-end, it works to some degree;
the standard library won't build in grade `il',
but you can build the standard library in grade `ilc'
and then at least some of the stuff in tests/benchmarks
builds OK in the `il' grade, linking against the `ilc' library.

The problems that prevent the library building in grade `il'
include the following:

        - MC++ interface:
                - add #using to *__cpp_code.
                - fix MR_Word casts for MC++ code
        - library:
		- definitions for undefined library types (c_pointer, type_desc)
		- RTTI

There's also the equivalence types problem, which I think is only
partly solved by `--intermodule-optimization'.

-- 
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
--------------------------------------------------------------------------