[m-dev.] abstract equivalence types & .NET / JVM

[Ralph Becket]

>     The problem with this approach is that it breaks our versioning
>     model; if a module defines an abstract type, then other
>     modules which make use of the abstract type may need to be
>     recompiled if the *implementation* (rather than just the
>     interface) of that module changes.

+

>     (b) We could put the definitions of abstract equivalence types in
> 	the `.int' files, but only for .NET/Java.
> 	We'd install two different copies of the `.int' files,
> 	and decide which one to use based on the grade.

or
 
>     (c) We could put the definitions of abstract equivalence types in
>         files with some new extension, e.g. `.typ'.

sounds least horrendous to me.  The versioning problem can be solved
by checking for changes in the .typ files (or whatever).

I'd really rather only pay for this stuff when I'm using it.

You mention that some of the stuff in the .int files may be inconsistent
wrt the .int2 files - can you give some details?

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