[m-dev.] hash consing

[Peter Schachte]

On Wed, Aug 25, 1999 at 05:18:30PM +1000, Fergus Henderson wrote:
> The language design decision is that anything which affects binary
> compatibility when intermodule optimization is switched off should
> go in the interface section. 
> 
> The rationale for that decision is that people should be able to write
> components (e.g. shared libraries, DLLs, and COM or CORBA components)
> in Mercury, and they should be able to modify the implementation section
> of a module without it affecting the binary interface to that component.

Being able to build components that can be shipped with just an
interface and without source code is a useful goal.  I support this
wholeheartedly.

But I still don't think you've presented a good justification for the
decision.  It is one way to achieve the component delivery goal, but
not the only one.  And this decision runs contrary to another goal I
haven't seen stated anywhere but I hope we can all agree on:

    A module's interface should contain all a client module needs to
    know to fully use that module, and nothing it doesn't need to
    know.

Other (I think better) ways to achieve the componentization goal
include:

    a)	Add a compiler switch that specifies that an object file is to
	be delivered as a component.  When this switch is specified,
	turn off optimizations that would cause intermodule
	predicate/function interfaces to be nonstandard.

    b)	Add extra pragmas to the language, which *would* placed in the
	interface section, which would allow lower-level control over
	interfaces.  For example, you might want to be able to specify
	which registers arguments would be passed in, and other aspect
	of the calling conventions.  These would, of course, be
	implementation and architecture specific.

    c)	Have the compiler generate extra information, in addition to
	the interface, that the compiler must use when compiling
	client modules.  This extra information indicates if and how
	calls to predicates/functions in the module should be
	specially compiled.  When this extra information changes,
	client modules must be recompiled (though they won't need to
	be type, mode, or determinism checked again).  In a perfect
	world, this extra information would be kept in the object
	file, but this isn't a perfect world, so this probably raises
	the OPNAF problem (Oh Please, Not Another File!).

    d)	Broaden the concept of "object file" and "linkage editing" to
	allow linking to generated appropriate code for every
	predicate/function call.  This, unfortunately, won't work for
	DLLs, but it's a nice model for components which will be
	statically linked, because it leaves a lot of scope for
	link-time optimization.


> Simon Taylor gave an even more persuasive reason in this particular case --
> tabling affects the legality of programs due to its affect on unique modes.

Much more persuasive, given the approach Mercury takes to uniqueness,
so my arguments don't apply in this case.  But I thought it was
important to take issue with your design decision, because I think it
unnecessarily confuses what an interface should be.

-- 
Peter Schachte                     [A computer is] like an Old Testament
mailto:schachte at cs.mu.OZ.AU        god, with a lot of rules and no mercy.
http://www.cs.mu.oz.au/~schachte/      -- Joseph Campbell 
PGP: finger schachte at 128.250.37.3  
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------