[m-dev.] foreign type syntax, the pain begins.

[Tyson Dowd]

On 01-Nov-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 01-Nov-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > So we are looking for something like:
> > 
> > :- pragma foreign_type(xmldoc, csharp, "System.Xml.XmlDocument").
> 
> That is my favoured option.
> 
> Either that or possibly with the order of the first two arguments switched,
> to be consistent with the ordering for `pragma foreign_proc'.

Ok, if we are going for this I guess 


:- pragma foreign_type(csharp, xmldoc, "System.Xml.XmlDocument").

> 
> ...
> > Now the first thing to do is consider that the scheme doesn't actually
> > work [...]
> > The problem is that you need to specify the assembly that each type
> > belongs to, and pass that as a command line option to the C# compiler.
> 
> Actually you specify which assemblies this source file references,
> and then the C# compiler reads in the meta-data for those assemblies
> and uses that to figure out which assembly each type is in.

Well now you are decoupling the information, which is OK for languages
like C# that don't do cross-module inlining, but not so great for
Mercury which does... 

> 
> > Unless you would like to have the mmc
> > commandline options also accept C# options
> 
> That seems to me like the logical approach...

Ugh.  Now you have to specify --csharp-assembly for any module that
might inlcude that code somehow (cross-module optimization for
instance).

I'd *really* prefer something like foreign_decl or IL.
Then we already have a mechanism to ensure the appropriate information
is propogated to modules that do cross-module inlining.


Amazingly, we have gone from my original proposal in which a single
declaration could specify a foreign type for all languages on the .NET
backend, to one where you have to specify:

3 foreign_type declarations, each with different syntaxes
1 foreign_decl for MC++
1 command line parameter, which must be manually propogated around Mmakefiles!


I think I would prefer to only accept IL foriegn_types -- it will be
much simpler to just write some code to parse the IL than to do this
stuff (or worse still, explain this mess to users!).

> 
> We already have `--cflags' and `--c-include-directory',
> and `--java-flags' and `--java-classpath', so why not
> `--csharp-flags' and `--csharp-assembly'?

I don't think this is a terribly convincing argument.
You're just arguing that we should copy their brokenness.
If C programmers and Java programmers all jumped off a cliff, would you?

I don't mind supporting these flags, but requiring them as the mechanism
for specifying the assemblies for foreign types is a ugly.

> A drawback of this approach is that it means if/when we get to the point
> of wanting to parse the syntax, so that you can use a single declaration
> rather than one for each language that you want to interface with,
> then we'd need to do the same work as the C# compiler.
> That is, we'd need to read in the meta-data for the referenced
> assemblies use that to figure out which assembly each type was in.
> That could be a lot of work and so we probably don't want to do that.
> So I guess the "master" syntax for the .NET back-end would have to
> be IL rather than C#.

Well, fortunately the IL syntax has almost all the required information
given.   So perhaps it would be best to only allow foreign_types
specified in IL.

> > For MC++ [...]
> > Or we could force the user to include an appropriate foreign_decl:
> 
> That's my preference.
> 
> :- pragma foreign_decl('MC++', "#using <System.XML.dll>").
> :- pragma foreign_type(xmldoc, 'MC++', "System::Xml::XmlDocument").

That's fine.

:- pragma foreign_type('MC++', xmldoc, "System::Xml::XmlDocument").

Would also be good.

-- 
       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-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------