[m-dev.] foreign type syntax

[Tyson Dowd]

On 31-Oct-2001, Holger Krug <hkrug at rationalizer.com> wrote:
> On Wed, Oct 31, 2001 at 08:03:42PM +1100, Fergus Henderson wrote:
> > For the Java back-end, I think the same thing applies: what's the
> > advantage *for Mercury users* of us inventing a new way of writing Java
> > types in Mercury syntax?  I don't see any.  I think our users would
> > prefer to write Java type names using Java syntax.
> 
> As a user I can say: I would.
> 
> > So for the Java back-end, I think we should use Java syntax for `pragma
> > foreign_type', and if we need to understand the structure of those types
> > (as would be the case if we're compiling directly to Java byte code
> > rather than to Java source) we can easily write a parser for Java types.
> 
> Why repeating Java code in Mercury sources ? Why not simple name those
> types in the `foreign_type' pragma by their full java type (i.e.:
> class) name and write a simple Java program which parses the
> Mercury code for `pragma foreign_type java ...' declarations, retrieves
> the type names used by the Mercury program and writes a full type
> description in whichever syntax the Mercury compiler implementors
> would like into a helper file (unvisible for the user/programmer).

This is a very different thing you are saying.

You are saying pragma foreign_type would be processed by a separate tool
which uses reflection to actually generate any required Java type
information in a special file.

It is another alternative -- but it would complicate the compilation
process quite a bit.

It was my intention to put this detailed type information into the .m
file as part of the foreign_type pragma. 
Perhaps it would be more acceptable if this information were put into a
separate file that is not intended to be accessed by users?

At any rate, this information is not urgently required at the moment, so
we can discuss this idea at leisure.

> The Java program is relatively simple to code using the Java
> reflection library methods.
> > More generally, speaking about interfacing with an arbitrary language:
> > I think it would be easier for Mercury users if the `pragma foreign_type'
> > syntax used the type syntax from the foreign language being interfaced with.
> 
> Or simply names the type and uses an approach as proposed above.
> 
> Additionally for Java classes one could automatically
> generate Mercury wrappers for the public/protected class methods and
> setter/getter methods for the public/protected class fields.
> 
> All this could be done invisible for the programmer/user by a Java
> program using Java reflection and writing appropriate Mercury wrapper
> code.

This is exactly what we do for .NET (except using a C# program).

But in this case we generate .m files from .NET components, and these
.m files have pragma foreign_type declarations to map the Mercury type
names down to .NET type names. 

> 
> > This approach has the following advantages:
> > 
> > 	- it's easy for users (they don't need to learn a new syntax,
> > 	  they can just use the syntax of the language that they are
> > 	  interfacing with)
> 
> Yes !
>  
> > 	- it's easy to implement in an OK manner
> > 	  (mapping foreign types to a generic type),
> > 	  without needing to parse the foreign language type syntax
> 
> For Java: Using Java reflection is also easy to implement
>  
> > 	- it's possible to implement in an ideal manner
> > 	  (although this may require parsing the foreign language type
> > 	  syntax)
> 
> For Java: not parsing the Java language, but using Java reflection. This is:
> * easy to implement
> * ideal for the user
> * easy for the user
>  
> > In contrast, the approach of inventing Mercury syntax for foreign
> > language types is easy to implement in an ideal manner, but this comes
> > at the expense of complicating the Mercury language and making things
> > harder for Mercury users.  
> 
> > I don't think that is a good trade-off.
> 
> I, too.

Please note that it was not my original intention that the :- pragma
foreign_type be written by hand.  I mostly expected them to be generated
by tools such as automatic interface generators.

But since I had to document the pragma in the reference manual, it has
instead become viewed as a user feature, which is fine -- there is a
place for a user feature like this one.

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