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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: limited/non-limited in Ada95 Date: 1997/10/21 Message-ID: #1/1 X-Deja-AN: 284786103 References: <3442C2A3.3781@bix.com> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 877425682 886 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-10-21T00:00:00+00:00 List-Id: Jon says <> The view for the implementation most certainly can have limited semantics. When you are writing garbage collectors, you certainly expect to do some pretty low level fiddling at the implementation level, where the fact that 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 an actual implementation, since there has been no demand for GC in GNAT so far (demand = serious customer willing to pay $) Robert Dewar Ada Core Technologies