[m-dev.] diff: type_name/1 et alt

Tyson Richard DOWD trd at students.cs.mu.oz.au
Thu Apr 24 17:43:10 AEST 1997

> Peter Schachte, you wrote:
> > 
> > Why shouldn't type_of(in, out) just be multi?  Why not allow it to
> > generate the names of equivalent types?
> Because that would be difficult to implement, inefficient, and not useful.
> If you want it to generate all equivalent types, the results would contain
> lots of junk, and the compiler would be forced to keep around big tables
> of equivalence types, even for types that were not used.

I should point out, that the concern I had for it being cc_multi was so
that is wouldn't be incorrectly specified - the behaviour of only giving
one answer is what you want, but not that expecation that it will always
give that answer.  The main concern was that the compiler shouldn't
optimise code that looks det but really isn't.

	:- type my_int == int.

	:- pred p(my_int::in) is det.
	p(X) :-
		Y = type_of(X),
		q(X, Y).

	:- pred q(int::in, type_info::in) is det.
	q(X, Y) :-
		Z = type_of(X),
		foo(Z, A),
		bar(Y, A).

	shouldn't be inlined and become...

	:- pred p(my_int::in) is det.
	p(X) :-
		Y = type_of(X),
		foo(Y, A), 
		bar(Y, A).

	if type_of is det.

Allowing access to _all_ equivalent types is much more difficult, and
probably not a lot of use.

       Tyson Dowd           #
                            #             Sign on refrigerator:
     trd at cs.mu.oz.au        #           Refrigerate after opening. 
http://www.cs.mu.oz.au/~trd #                  - C. J. Owen.

More information about the developers mailing list