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

[Tyson Dowd]

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:
> > 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).

Well then you have to discuss what "interface with ... as if it were
(another language)" means.  Which is a tricky concept.  

This only applies for types, nothing else (yet).  So I will try to say something
along those lines in the foreign_type general documentation -- it will
be something about how you can sometimes use type A defined in languages
X as if it were equivalent type B in language Y if they have compatible
conventions, and we support it, using some rules for type equivalence
that depend on X and Y.

But honestly, I think it's actually easier just to spell out the cases
in which it works, as the generalization is quite complex and not
particularly useful until you look to see which combinations the
implementation suppoorts.

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

Ok, fair enough.

> > > > +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"?

s/backends/languages/ that was just a thinko, sorry.

Not we support.  It works for *all* .NET languages with :- export.
With foreign_proc it doesn't but that's covered by the fact that
foreign_proc is a different thing to foreign_type.

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

Ok, we shouldn't really be talking about backends, that is a problem.
Unfornately Pete and I used ".NET backend" and "il backend"
in daily conversation every day for 3 months so I'm a bit stuck on it.

It should be ok to discuss .NET langauges at a group, but in the
interests of getting this change checked in the same year it was
started, I will do as you say.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------