[m-dev.] for review: prelim support for hash consing

[Zoltan Somogyi]

> > Perhaps hash_cons should be the name of this pragma?
> 
> I prefer `memo_cons', since that is less implementation-oriented.

We couldn't agree on the best name for the pragma, but I think that
"canonical", "standard" and variations thereof are probably better
than either hashcons or memocons.

> I think
> 
> 	In `pragma memo_cons' declaration:
> 	  ambiguity error: constructor `foo/2' appears in multiple types.
> 
> would be more consistent with the way we format other error messages.

I think the format of the error message is irrelevant, because the pragma
should be such that there is no ambiguity. The design I discussed with Fergus,
which his original mail mentioned, had two kinds of pragmas:

:- pragma hash_cons(typector/arity)
:- pragma hash_cons(typector/arity, [ctor1/arity1, ctor2/arity2, ...])

I haven't looked at Peter's diff yet, only the responses to it, but it seems
to me that an implementation of this proposal can't get an error of the
above type.

>> The mangled name could maybe be a little more robust... I'm not sure what,
>> though.

I thought we decided that the best approach would be to reserve a character
('_', or '$' or ...) so that only compiler-created predicates can start
with that character. User-created predicates whose names start with that
character (names which must be quoted) would then have another character
inserted at the front by the compiler. Implementing this system would seem
to me to be a job best done by Fergus, or possibly Simon.

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