Re: opaque type proposal

[Pavel.pa@Xerox.COM]

I don't consider either of Jonathan's two problems with single-inheritance to be
significant.  Here's why.

The claim is that single inheritance makes type-checking and predication slow.
I dispute this.  Certainly if you insist that, say, the first slot of every
opaque object should contain the special value identifying elements of its type,
then yes, indeed, you will have to check for several values.  However, this is
not necessarily so.  Consider this set of definitions:

	(define one (make-record-type 'one '(a b)))
	
	(define two (make-record-type 'two '(c d) one))
		; two inherits from one
	
	(define three (make-record-type 'three '(e f) two))
		; three inherits from two
	
Then I would expect to see the predicates for these types written as

	(define (one? x)
	   (and (record? x)
	        (>= (record-length x) 3)
	        (eq? (record-ref x 0) one-tag)))
	
	(define (two? x)
	   (and (record? x)
	        (>= (record-length x) 6)
	        (eq? (record-ref x 3) two-tag)))
	
	(define (three? x)
	   (and (record? x)
	        (>= (record-length x) 9)
	        (eq? (record-ref x 6) three-tag)))

Clearly, the result of

	((record-constructor three) 1 2 3 4 5 6)

would be a length 9 record like this:

	Slot	Slot
	Index	Value
	-----	-----
	  0	one-tag
	  1	1		; value for the A slot
	  2	2		; value for the B slot
	  3	two-tag
	  4	3		; value for the C slot
	  5	4		; value for the D slot
	  6	three-tag
	  7	5		; value for the E slot
	  8	6		; value for the F slot

Using this representation, no operation takes other than constant time or,
indeed, any longer than it would without any inheritance at all.

I thus conclude that single inheritance is not inefficient.

Jonathan's other problem was that constructor procedures are no non-modular.
This is only true to the extent that modules export their record-type objects to
the outside world.  The major uses for inheritance that I have in mind do not
involve cross-module use of record-type objects.  I claim that this
non-modularity is exactly as much a problem as for any other exported value; if
I change the number of arguments required for some exported procedure, I have
just the same kind and degree of problem as when I change the number of slots in
an exported record-type object.

I thus conclude that the modularity problem is not specific to opaque types thus
should not be an issue in this discussion.

	Pavel