[m-dev.] For review: base_type_functors

[Tyson Richard DOWD]

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

Yes, it would, but it would make accessing the pseduo-typeinfos
less efficient (they're more likely to cause a cache miss, and if
you don't need the functor and tags, you're carrying a lot of baggage
in your cache). 

It all depends what you are going to be doing more often, using
the functor string and tag representation, or using the argument
pseudo-typeinfos.

I was trying to optimise the layout of simple vectors for deep_copy
(esp. accurate gc), since other operations (eg io__write and io__read)
are probably going to be dwarfed by I/O, but GC needs to be fast.

I've documented this in the code now, but I'm prepared to change it
if you want it the other way.

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

Yep, its a bit unclear. I've reworded it in the new version.

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

True. But it avoids a (small) double maintenance problem in code that
needs to decode the information. Perhaps it's better to live with that
problem. I'll remove this comment, and fix the code that relies on it
when ohutch commits the new macro for decoding type_layouts. 

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

Working on it.

-- 
       Tyson Dowd           # "Most people's C code should be indented
                            #  six feet downward and covered with 
     trd at cs.mu.oz.au        #  dirt."
http://www.cs.mu.oz.au/~trd # - Blair Houghton, on C code indentation