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

[Fergus Henderson]

On 25-Aug-1999, David Glen JEFFERY <dgj at cs.mu.OZ.AU> wrote:
> > compiler/make_hlds.m:
> >     The core of the change.
> >     For every 
> >         :- pragma memo_cons(Constructor/Arity).
> >     Construct a function
> >         hash_cons_C(X1, ..., XN) = C(X1, ..., XN).
> >     where hash_cons_C is a suitably name mangled function.
> 
> Perhaps hash_cons should be the name of this pragma?

I prefer `memo_cons', since that is less implementation-oriented.
Note that the memoing won't necessarily be implemented using hashing;
depending on the argument types, and on whether the argument types
are themselves memoed, it may be done using tries or other data structures.

> > +			prog_out__write_context(Context),
> > +			io__write_string("Error: constructor '"),
> > +			hlds_out__write_cons_id(cons(Constructor, Arity)),
> > +			io__write_string("' in multiple types.\n"),
> > +			{ Info = Info0 }
> > +
> > +			% XXX should list what those types are if -E
> 
> This error message really isn't very helpful either... it just tells you that
> the type is visible in multiple types. It doesn't mention why that is a problem
> (ie. because of the memo_cons pragma). I guess it mentions the line number of
> the pragma, but I still think you could say something like:
> 	Error: pragma memo_cons declaration for constructor `foo/2' which
> 	       appears in multiple types.

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.

And the list of possible matches should occur even if `-E' is not specified:

	In `pragma memo_cons' declaration:
	  ambiguity error: constructor `foo/2' appears in multiple types.
	  Possible matches occur in types
	  `bar:t1', `baz:t2', ..., and `quux:tn'.

The verbose error message for `-E' should explain that
if the types occur in different modules, then you can resolve
the ambiguity by adding a module qualifier, but if the same name/arity
is used for different types within a single module, then the only solution
is to rename one of the constructors.

> > +:- pred make_hashcons_func_name(sym_name::in, arity::in, type_id::in,
> > +		string::out) is det.
> > +
> > +make_hashcons_func_name(ConsName, ConsArity, TypeName - TypeArity, Name) :-
> > +	prog_out__sym_name_to_string(ConsName, ConsStr),
> > +	prog_out__sym_name_to_string(TypeName, TypeStr),
> > +	string__format("cons_%s/%d_%s/%d", [s(TypeStr), i(TypeArity),
> > +			s(ConsStr), i(ConsArity)], Name).
> 
> The mangled name could maybe be a little more robust... I'm not sure what, 
> though.

Also you should modify profiler/demangle.m and util/mdemangle.c
to demangle such names.

> > +	% sym_name_to_term(SymName, Args, Term):
> > +	%	convert a symbol name with an associated list of terms
> > +	%	into a term.
> > +:- pred prog_out__sym_name_to_term(sym_name, list(prog_term), prog_term).
> > +:- mode prog_out__sym_name_to_term(in, in, out) is det.
> 
> Isn't there already something like this somewhere else?

Yes, I think prog_util__construct_qualified_term is what you are looking for.

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