[m-rev.] diff: implement io__stream as foreign type

[Peter Ross]

fjh wrote:

> On 08-May-2002, Peter Ross <peter.ross at miscrit.be> wrote:
> > Once this bootchecks, I will check it in.
> ...
> > Change the type io__stream to be implemented using pragma foreign_type.
> > This should make it easier to port the library to the il grade.
>
> This change broke
> (1) the tests of the hlc.agc grade
> (2) the `--target asm' back-end
> (3) bootstrapping on taifun, apparently since a sufficiently
>     recent compiler hadn't been installed on taifun
>
> I have since fixed (1).
> I will post a fix for (2) shortly.
> But in the mean time, I'm going to back out this change.
>
> In general, the current implementation of `pragma foreign_type'
> for C looks broken in several important respects:
>
> - The interface of procedures exported with `pragma export'
>   should be the same regardless of the back-end, but this
>   is currently not the case.
>
> - The foreign name should be used for `pragma export'.
>
I thought that you didn't want to change the rules for types at the C
interface.  I much prefer using the foreign name when doing the pragma
export.

> - The MLDS->C back-end should use `MR_Box', not the foreign type
>   name, for representing foreign types internally.
>   This is needed to maintain binary compatibility with the
>   `--target asm' back-end.
>   (The foreign name should be used only for `pragma foreign_proc'
>   and `pragma export', not internally.)
>
Ahh I misunderstood what you meant by using MR_Box, I thought MR_Box was at
the external interfaces, I understand now.

> - All reasonable C types should be handled, regardless of their size.
>   The Mercury compiler should do boxing/unboxing automatically,
>   if needed.
>
I have been thinking about this, and I think the way to go would be to
provide attributes with every foreign type, similar to what we do with the
foreign procs.  This would allow one to specify whether or not the type was
boxed or not.  The attributes could also be used to provide implementations
for the comparison and unification predicates.  If we could also provide a
method to specify the RTTI for the type then we could move all the builtin
types out of the compiler and into the libraries.  I guess the best approach
would be to add an attribute whether or not this type has had RTTI defined
for it.  The only problem that I see is that you would have to repeat a lot
of the information in each foreign_type definition.  Maybe it would be
better if there was another pragma, foreign_type_attributes, which would be
used to specify the global attributes.

> I will have a go at fixing some of these.
>
Thanks for your help Fergus.  I am currently working on fixing up the
managed C++ interface so that it works with high level data.

Pete

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