I'm confused about type promotion (was: [Nickle]Tonight's topics)

[Carl Worth]

On Jul 24, Bart Massey wrote:
 > 2) There should be no such thing as a structured value some
 >    of whose elements are <undef>.

I agree with this. This will be a nice improvement.

 >    Yet, the language should not try to guess what value things
 >    should be initialized to.

I agree that the language should never guess. But might it not make
sense for the programmer to be able to explicitly provide default
initialization values in the definition of a structured value type?

I started thinking along those lines as I have been considering the
promotion rules in nickle, (which, frankly I haven't quite grasped yet
-- it doesn't help that I can never keep straight the directions of
downward/upward promotion and sub/super-types).

What prompted my train of thought was the surprising behavior of the
"structure compatibility rule" mentioned in the nickle tutorial,
(which is coming along quite nicely by the way -- thanks!):

	a struct value is compatible with a struct type if
	the struct value contains all of the entries in the
	type. For example:

	typedef struct {
		int	i;
		real	r;
	} i_and_r;

	typedef struct {
		int	i;
	} just_i;

	i_and_r	i_and_r_value = { i = 12, r = 37 };
	
	just_i	i_value;

	i_value = i_and_r_value;

	The assignment is legal because i_and_r contains all
	of the elements of just_i. i_value will end up with
	both 'i' and 'r' values.

I'm still a bit confused about the state of the variable i_value at
the conclusion of this exercise. Empirically, it seems to be of type
just_i still since I can pass it to a function accepting an argument
of type just_i. Also, I can not access the r field directly from it.

However, I can also do things with this variable that I can not do
with a straight value of type just_i, for example, I can assign it to
a variable of type i_and_r, (assigning both the i and the r values).

So what kind of object do we have at this point? It seems to be a
strange mix of both types, (which, admittedly, I can see some uses
for).

I tried to compare this with what happens between the int and rational
types which seem to have a similar relationship as the just_i and
i_and_r types above. But, it's an error to try a similar assignment
with these types:

	> rational r = 12 / 37;
	> int i;
	> i = r
	Unhandled exception "invalid_argument"
        	"Incompatible types in assignment"

However, assignment in the other direction works of course, (while
failing for the structure values):

	> int i = 12;
	> rational r = i;

	> just_i i = { i = 12};
	> i_and_r r = i;
	Unhandled exception "invalid_argument"
        	"Incompatible types in assignment"

I may be thinking about this the wrong way, but it seems that
assigning an int value to a rational because nickle "knows" the
correct value for the missing field. So, perhaps, (with no guessing),
nickle could allow the programmer to specify default initialization
values so that similar behavior could also be possible for structured
values?

That might even make it possible for Bart to keep his convenient
automatic structured value creations, no?

 >    Ergo, though I was fond of them, the automatic implicit struct
 >    and array creation have to go.  This will ensure prompt run-time
 >    detection of trouble, and remove a serious definitional problem
 >    in the type system.

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725