[m-dev.] hash consing

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Aug 25 17:18:30 AEST 1999


On 25-Aug-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> Resurrecting an old thread...
> 
> On Thu, Aug 12, 1999 at 08:56:35PM +1000, Fergus Henderson wrote:
> 
> > > Tabling seems like an implementation detail; why should it be part of
> > > the interface for a module?
> > 
> > In Ada, this would belong in the "private" part of the module interface.
> > The reason it belongs in the interface for exported types is that
> > if you add or remove these declarations, then code using that type
> > must be recompiled.
> 
> This is a good reason for an implementation decision, but not a very
> good reason for a language design decision.  This is the latter sort
> of decision.

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.

Supporting component-based programming in this way does of course
impose certain constraints on the implementation, e.g. it prevents
intermodule optimization.  So not all Mercury implementations will
want to support it.  But it is a very useful feature and so the language
should be designed in a way that _allows_ implementations to support it.

P.S.
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.
But I thought it would be worthwhile to elaborate on this design principle
anyway.

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



More information about the developers mailing list