[m-dev.] For review: Add implementation of reference types (global heap)

[Fergus Henderson]

On 09-Jun-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> On Tue, 9 Jun 1998, Fergus Henderson wrote:
> > On 09-Jun-1998, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> 
> > > > In other parts of the Mercury library/extras, the convention has
> > > > been to use `foo.m' for the non-trailed version and `tr_foo.m'
> > > > for the trailed version.
> > > But they're not quite the same thing are they?
> > 
> > Now that you point it out, no, they are not quite the same.
> > 
> > The implementations are pretty similar (trailed and non-trailed versions),
> > but the interfaces are different.
> 
> Actually, the interfaces are pretty much identical.  It's only the behavior
> that's different.

We're talking about different things here.
I meant the implementation of tr_store and reference are pretty similar,
and the implementation of store and nb_reference are pretty similar,
its just the respective interfaces that are different.
I think you're saying that the interfaces of store and tr_store are
pretty similar, and the interfaces of reference and nb_reference
are pretty similar, with their respective implementations being different.
Both of these points are correct.

> > I still think there's a fairly strong analogy between
> > nb_reference/reference and store/tr_store.
> 
> I don't see it.  In the store case the semantics of the operations are the
> same, it's just that one version implements the semantics for more cases
> (modes) than the other.

That is, the declarative semantics are the same, but the operational semantics
are different.

> Both references and nb_references implement all of
> their semantics, but their (operational) semantics are totally different. 

Well, references and nb_references don't have any declarative semantics.
So this doesn't quite break the analogy.  But I see what you are
getting at.

> Another way to look at it is that *in principle* store and tr_store could
> (and I would argue, should) be the same type or type class, with the Mercury
> compiler choosing the right implementation based on usage.  But it would
> never make sense to merge reference and nb_reference into a single type or
> type class. 

OK, you've convinced me ;-)

> > > > Our standard naming convention for type names in C is to use
> > > > "MixedCaseIdentifiers".
> 
> Pity.  I find MixedCaseIdentifiers only marginally easier to read than
> runtogetheridentifiers, and much less readable than
> underscore_divided_identifiers.

I'd be happy to go with Mixed_Case_With_Underscores for C type names,
so long as this is done consistently.  But making that change
would be quite a bit of work.

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