[m-dev.] For review: base_type_functors

[Fergus Henderson]

Tyson Richard DOWD wrote:
> 
> This is stage 1 of changes designed to allow io__read/3 to be
> implemented. It will also allow the other code dealing with
> runtime type information to be significantly simplified.

The log message should always include a rationale,
so the above text should be part of the log message.

What are stages 2+ going to be?


> +% These global constants are used by the predicates functor/3, arg/3
> +% and expand/4 in std_util.m, and solutions in non conservative-gc grades. 

I suggest

   % and expand/4 in std_util.m, and by deep_copy(), which is used by
   % solutions in non conservative-gc grades. 

> +% Tag 1 - 	SIMPLE  Word = pointer to simple vector
> +%
> +% SIMPLE: Simple vector contains 
> +% 	  - the arity of the functor (N)
> +% 	  - N pointers to pseudo-typeinfos (of each argument),
> +% 	  - a pointer to a string containing the name of this
> +% 	    functor.
> +%	  - A word containing a representation of the primary and
> +%	    secondary tags of this functor

It would probably make accessing the functor name and the functor tags
representation easier, and slightly more efficient, if the
variable-size part (the N pointers to pseudo-typeinfos) of this
simple vector were at the end, rather than in the middle.

> +% Note: Future Work
> +% 	By using the indicator in this table, it may be much easier to
> +% 	encode the base_type_layout tables - for example, no encoding
> +% 	for equivalences needs to be done, the special
> +% 	base_type_functors table could be augmented with a description
> +% 	of which builtin is being used, so the encodings of constants
> +% 	can be simplified, and so can enumerations and no_tags. In fact, 
> +% 	the base_type_layout table could really just be used to
> +% 	determine whether a tag is simple or complicated.

I don't fully understand this comment.

> +	% no_tag vector:
> +	% 	- no_tag indicator 
> +	% 	- pseudo_type_info (of the argument)
> +	% 	- functor name.
> +	% 	- tag information (bogus, see comment in code below)
> +	%
> +	% NOTE: Since the no_tag indicator is 1, this is the
> +	%       same data as a simple tagged functor of 
> +	%       arity one would have, which is often convenient
> +	%       because for some purposes no_tags should be
> +	%       treated like simples.
[...]
> +		% create tag information
> +		% since it's a no_tag, we'll give it a tag value of 0
> +		% to be consistent, but this doesn't really have any
> +		% meaning.
> +	base_type_layout__encode_cons_tag(simple_tag(0), ConsTagRvals, 
> +		LayoutInfo1, LayoutInfo),

Uh, my gut feeling is that the stuff in the "NOTE:" is probably a
little bit too clever; relying on coincidences like this and building
them in as assumptions in the code makes maintenance more difficult,
firstly because people may change things without realizing that this
assumption exists (this seems to be the only place it is mentioned),
and secondly because even if they do realize the assumption is being
made, it may be difficult to preserve its correctness.

> -	(const Word *) string_const(""io__stream"", 10)
> +	(const Word *) string_const(""io__stream"", 10),
> +	((Integer) 0)	/* Primary tag 0, no secondary tag */
>  };

Please don't hard-code values like these in io.m; they should
be #defines in type_info.h or somewhere like that.

Oh, look a much better fix for that is to just define

	:- type io__stream == c_pointer.

and delete that whole section of code.


Can I please see another diff after you've addressed those issues?

Thanks,
	Fergus.

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