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

[Fergus Henderson]

On 18-Apr-2001, Ralph Becket <rbeck at microsoft.com> wrote:
>     
> >     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).

Occurrences of the versioning problem can be *detected* by checking for
changes in the .typ files.  But that just allows the compiler to alert
the user to the presence of this problem, it doesn't *solve* the problem.

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

Agreed.

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

Currently the information in the .int2 file is duplicated in the .int file --
the .int file is a superset of the information in the corresponding .int2 file. 
So if both files are read in, the result is a duplicate declaration error.
This means if you read in the .int file for a given module, you must not
read in the .int2 file, and vice versa.

Likewise, the .int0 file is a superset of the .int file.
So in fact you can only read in at most one of the .int0, .int, and int2 files.

That is one of the constraints.  There are quite a few others:

	- If you read in a .opt file, then you need to read in the
	  corresponding .int (or .int0) file, and the .int (or .int0) files
	  for any modules directly imported by the .opt file.
	  This is because pragmas and clauses in the .opt file can
	  refer to predicates or functions declared in those .int (or .int0)
	  files.

	- If you read in a .int file, then you need to read in the
	  .int2 (or .int or .int0) files for any modules imported by
	  that .int file.  This is needed because the .int file may
	  refer to types defined in the imported modules.

	- If you read in the .int0, .int, or .int2 file for a nested module,
	  then you need to read in the .int0 file for the parent module.
	  This is needed because the nested module may refer to types defined
	  in the implementation section of the parent module.

There's also some constraints related to particular options,
and a bunch of constraints relating to .trans_opt files.

Figuring out which files need to be read in -- i.e. solving this set of
constraints -- is quite tricky.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------