[comp.lang.ada] why field names must be unique

emery@d74sun.mitre.org (David Emery) (12/15/89)

Bill Wolfe sez:
>   P.S. I could kick myself for not putting in a 9X suggestion that
>        the rule about all field names being distinct be set up such 
>        that one can do variant records whereby each of the mutually
>        exclusive variants are identically named...  that rule makes 
>        us add contrived suffixes to the field names just to get them 
>        past the compiler, which would appear to be very nonproductive.

I used to think that requirement was a unnecessary pain in the butt,
too.  Then I thought about it a bit.  Consider what would be involved
with the following:
		
	type enum is (a,b,c,d);
	task type foo_task;
	type bar_record is record
	  x : integer;
	  y : float;
	end record;
	type t (discr : enum := a) is record
	    case discr is
	      when a =>
		x : integer;
	      when b =>
	        x : foo_task;
	      when c =>
		x : bar_record;
	      when d =>
		y : float;
		x : integer;
	    end case;
	end record;
	type t_ptr is access t;

	item, some_object : t_ptr;

	begin
	  ...		-- allocate item, some_object with
			-- 'arbitrary' values for discr
	  some_object.x := item.x;
	end;

Consider all the work that would have to be done to resolve item.x and
some_object.x . This is not decidable at compile time, in part because
both item and some_object are access t.  Even if we knew that
some_object.x was of type integer, overload resolution fails because
there are two values of t.x that return integer, at different
locations in the record).  In general, the code generation for the
assignment would be horrendous!

With record component names being unique, first the compiler can do
full type checking, and second a record field reference is ALWAYS a
simple (static) offset within the record object.

				dave emery
				emery@aries.mitre.org