home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!netnews-2.srv.cs.cmu.edu!moss
- From: moss@cs.cmu.edu (Eliot Moss)
- Newsgroups: comp.lang.modula3
- Subject: Re: references, objects & m3
- Message-ID: <MOSS.93Jan24164146@CRAFTY.cs.cmu.edu>
- Date: 24 Jan 93 21:41:46 GMT
- Article-I.D.: CRAFTY.MOSS.93Jan24164146
- References: <C1BsMI.5Ay@undergrad.math.waterloo.edu>
- Sender: news@cs.cmu.edu (Usenet News System)
- Reply-To: moss@cs.cmu.edu
- Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
- Lines: 26
- In-Reply-To: papresco@napier.uwaterloo.ca's message of 23 Jan 93 21:20:41 GMT
- Nntp-Posting-Host: crafty.fox.cs.cmu.edu
-
- I don't understand why you're using REF OBJECT ... END instead of just OBJECT
- ... END. The latter is implementation essentially as REF RECORD ... END, but
- with the additional semantics of OBJECT method invocation, subtyping, etc. You
- should probably just delete the level of REF in your binary tree stuff. Maybe
- you want somehting like this:
-
- TYPE Node = RECORD
- This : Sortable;
- Left, Right: REF Node;
- END;
-
- You are quite right in noting that REF S is not a subtype of REF T, even when
- S is a subtype of T. Adding such subtyping rules to the language has various
- undesirable consequences, mainly in complexity, though one may be able to come
- up with type systems in which such subtyping judgements would be sound. See
- the section of the Nelson book "How the Language Got Its Spots" for further
- discussion of rationale for the subtyping rules.
- --
-
- J. Eliot B. Moss, Associate Professor Visiting Associate Professor
- Department of Computer Science School of Computer Science
- Lederle Graduate Research Center Carnegie Mellon University
- University of Massachusetts 5000 Forbes Avenue
- Amherst, MA 01003 Pittsburgh, PA 15213-3891
- (413) 545-4206, 545-1249 (fax) (412) 268-6767, 681-5739 (fax)
- Moss@cs.umass.edu Moss@cs.cmu.edu
-