[m-rev.] for review: new foreign_type syntax

[Fergus Henderson]

On 06-Dec-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 06-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 06-Dec-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > Fix and enable the new foreign_type syntax.  We now accept declarations
> > > such as:
> > > 
> > > :- pragma foreign_type(il, xmldoc, "class [System.Xml]System.Xml.XmlDocument").
> > > Index: doc/reference_manual.texi
> > ...
> > > @@ -5004,6 +5007,38 @@
> > >  
> > >  @c -----------------------------------------------------------------------
> > >  
> > > + at node Using foreign types from Mercury
> > > + at section Using foreign types from Mercury
> > > +
> > > +Types defined in foreign language can be defined in Mercury using 
> > 
> > s/foreign language/a foreign language/
> > 
> > Also s/defined in Mercury/accessed in Mercury/ ?
> > 
> > > @@ -5085,6 +5120,7 @@
> > >  
> > >  @menu
> > >  * Interfacing with C 		:: How to write code to interface with C
> > > +* Interfacing with .NET CLR	:: How to write code to interface with .NET CLR
> > >  * Interfacing with C# 		:: How to write code to interface with C#
> > >  * Interfacing with IL 		:: How to write code to interface with IL
> > >  * Interfacing with Managed C++ 	:: How to write code to interface with
> > 
> > This is in a section titled "language specific bindings".
> > All the other entries here are languages, but ".NET CLR"
> > is not really a language.  So I don't think it belongs here.
> 
> I will see whether I can make it a subsection of its own (with C#, IL
> and MC++ underneath it).

Well, that might be an improvement, but I'm not sure that is enough to
solve all of the conceptual problems here...  I think it might be
better to just put this information in the "Interfacing with IL"
section, with pointers to it from the relevant other sections.

There should also be some general introduction material that makes it
clear that you may be able to interface with language X as if it were
language Y provided that X and Y have the same interface conventions
(as is the case e.g. for all languages compiled to .NET CLR code).

> > > + at node Using pragma foreign_type for C
> > > + at subsubsection Using pragma foreign_type for C
> > > +
> > > +This pragma is currently not implemented for C backends.
> > 
> > s/not implemented for C backends/not supported for C/
> > (We should be talking about languages, not backends.)
> > 
> > Also it would be a good idea to mention here that the
> > `c_pointer' type can be used instead (giving an example).
> 
> I can mention it, but perhaps we should have given examples when
> we added c_pointer to the library...

Actually we did: see the "Using C pointers" section of the "C interface"
chapter.

But if the "Interfacing with foreign code" is intended to eventually
suffice as a replacement for the "C interface" chapter, then it should
be mentioned here too.

> > > +The .NET CLR @samp{pragma foreign_type} declaration is of
> > > +the form:
> > > +
> > > + at example
> > > +:- pragma foreign_type(il, @var{MercuryTypeName}, @var{DotNetForeignType}).
> > > + at end example
> > 
> > The language in this `foreign_type' declaration is `il'.
> > So why isn't this in the "interfacing with IL" section?
> 
> The foreign_type works for all .NET backends.

?

AFAIK we only have one .NET back-end (modulo issues with --high-level-data etc.
which are not relevant here).

Do you mean "all .NET languages"?
Or maybe "all the .NET languages that we support"?

> il is the syntax used to specify the types.
>
> If you put it in the IL section, people who want to find out how to
> interface to C# or MC++ won't find it.

So add pointers to this section in the "interfacing with C#"
and "interfacing with MC++" sections.

That way, we avoid this conceptual problem of talking about
back-ends rather than languages.

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