[comp.lang.eiffel] Generic class restriction

tynor@prism.gatech.EDU (Steve Tynor) (03/07/90)

Consider (Eiffel 2.2b):

	class FOO [T -> NUMERIC] export
	   bar 
	feature
	   bar (v : T) : T is
		 -- barify `v'
	      do
		 result := v * v;
	      end;
	end
and
	class BAZ
	feature
	   x : INTEGER;
	   z : FOO [like x];
   	   Create is
		 -- demonstrate the bug
	      do
		 z.Create;
		 io.putint (z.bar(x));
	      end
	end

When attempting to compile these classes, the following error results:

	"baz", 8: Basic type may not be used as actual generic type
	   corresponding to a constrained formal generic parameter
	es: error in pass3

It seems  probable  that  the cause of  the  error is  that  the  code
generation  for  the  generic  classes   assumes  that  actual generic
parameters will be class  types and therefore  incompatible with basic
types (even  if those types   have conforming features).  However,  in
principle,   a compiler could recognize    (at  the time   of  generic
instantiation) that a basic type was being passed as an actual generic
parameter.  The compiler could then regenerate code for those affected
features with  the newly acquired   knowledge of the   formal's actual
(basic) type.   Multiple instantiations  of the generic type  with the
same actual types  could share  the code  thus produced - as a result,
the space penalty would not be prohibitive.

[ Note: In many (most?)  cases (e.g.  LIST[T]), the formal  generic is
  just a place holder and T is never actually needed to  generate code
  - thus deferring code generation is often (usually?) unnecessary. ]

This  is an apparently unecessary restriction  to an otherwise elegant
language introduced in the name of efficiency.  Yet, here at least, it
seems that it would be possible keep the language pure without loss of
efficiency. 

Comments?  Are  we  missing  something?    If this   is  not  just  an
implementation restriction, but rather of  the language itself, please
point us toward the appropriate section  in "Eiffel: The Language". Is
this restriction removed in 3.0?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
inherit STD_DISCLAIMER

	Steve Tynor & Fred Hart
	Artificial Intelligence Branch
	Georgia Tech Research Institute

	tynor@prism.gatech.edu
	cfh@pyr.gatech.edu