[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:
> > > On 06-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > 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.  

All I mean by that is to "use Mercury foreign language interfacing
declarations which specify language X to interface to code that is
actually written in a different language Y".

So I'm thinking of something like this:

	You can use Mercury foreign language interfacing declarations
	which specify language X to interface to code that is actually
	written in a different language Y provided that X and Y
	have compatible interface conventions.

The concept which is really fuzzy here is the notion of "compatible
interface conventions".

> This only applies for types, nothing else (yet).

Well, it applies to `pragma import' too.
For example, see samples/c_interface/mercury_calls_fortran.

I guess that will be `pragma foreign_proc_import' (or whatever
we decide to call it) for this chapter.

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

That would be fine too.

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

It would be fine with me if we group all the .NET languages together.
I just want the discussion to be based on languages rather than back-ends.

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