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,d1df6bc3799debed X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Syntax for tagged record types (was Re: Not intended for use in medical,) Date: 1997/05/25 Message-ID: #1/1 X-Deja-AN: 243795344 Distribution: world References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com> <33828299.2A3@world.std.com> <33850721.49BF@sprintmail.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-05-25T00:00:00+00:00 List-Id: In article mheaney@ni.net (Matthew Heaney) writes: > >For limited types, the only way around this is to hide them behind > >access types for them. Then things again work just fine - except for > >storage management issues. Hence, the need for GC. Limited types are > >really extremely useful. Unfortunately, much of this is lost without > >GC support. > > But I'm trying to avoid using any heap. If I have to allocate an object, > I'd rather it go on the stack. Limitedness forces me to put the object on > the heap. Why? Who said it forces you to put them on the heap? It's your wanting to have all sorts of "constructors" for them with all sorts of parameters and named all sorts of ways and such that basically makes this necessary. > It's just a syntactic quirk of the language (the confusion > of assignment and initialization) that prevents me from initializing a So, why are you using limited types anyway? > If we could eliminate those times when a limited object must be put > on the heap, then there would be less motivation for a garbage > collector. Talk about having the cart before the horse! > It's not clear to me, though, why you even need GC support. If heap is > needed to implement an abstraction, the abstraction writer can sweat all > the memory management details by using storage pools and controlled types. > What's the problem? Go ask a typical C or C++ programmer for starters. Highly threaded and interconnected structures are extremely common and are often the best (most natural, most efficient, most flexible, etc) implmentations of many abstractions. Such structures basically _require_ heap style allocation and reference interconnection. Sure, it is _possible_ to manage this sort of complexity by hand, but it is extremely time consuming grunt type work - the very thing that computers are good at! That's the problem and that's the reason why GC is so useful. Why use the stack? Just allocate everything statically like old Fortran. Hey, you can make this work for anything - who needs all that assistance you get with stack allocation? /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com