From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,34d47d048b177d0b X-Google-Attributes: gid103376,public From: jsa@alexandria.synquiry.com (Jon S Anthony) Subject: Re: limited/non-limited in Ada95 Date: 1997/10/21 Message-ID: #1/1 X-Deja-AN: 282283393 Distribution: world References: <3442C2A3.3781@bix.com> Organization: PSINet Newsgroups: comp.lang.ada Date: 1997-10-21T00:00:00+00:00 List-Id: In article dewar@merv.cs.nyu.edu (Robert Dewar) writes: > The view for the implementation most certainly can have limited semantics. Anything is _possible_. It's just not reasonable in this case. Of course I looked at this sort of approach. It sucks even more than forcing reference semantics. > the full view is limited is not a problem. But this way you can preserve > the abstraction. I see no problem in writing a GC implementation using > this approach, and in fact we worked out exactly how to do this in the > context of the GNAT project, though no one ever followed through with I'm not talking about situations where you can have privleged knowledge and support by/from the compiler. Sure, in that sort of case the entire issue is irrelevant (but proprietary and tied to a single implementation). /Jon -- Jon Anthony Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari