[m-dev.] foreign type syntax

[Holger Krug]

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

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

-- 
Holger Krug
hkrug at rationalizer.com
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------