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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interesting containers problem. Date: Fri, 17 Apr 2015 23:06:38 +0200 Organization: cbb software GmbH Message-ID: <1uwarjhgizxpn$.yej2gjfg1nhl.dlg@40tude.net> References: <8def4a86-5835-4368-b414-63e12f1074e8@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: w2sqUGEBZqsVBYNL7Ky3Kg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:25539 Date: 2015-04-17T23:06:38+02:00 List-Id: On Fri, 17 Apr 2015 15:45:05 -0500, Randy Brukardt wrote: > "Peter Chapin" wrote in message > news:alpine.CYG.2.11.1504171506500.2268@WIL414CHAPIN.vtc.vsc.edu... >> On Fri, 17 Apr 2015, Shark8 wrote: >> >>> And that's all well and good; however, there is one limitation here that >>> is revealed when you need nesting scopes -- there is, apparently, no way >>> to define an Element_Type to feed to Indefinite_Ordered_Maps which is an >>> instance of Indefinite_Ordered_Maps.Maps or an instance of Variable_Data >>> (by way of a variant record; even one which is forward declared). >>> >>> What would be the proper way to handle this sort of situation? >> >> Perhaps using access types directly? What if the Element_Type of the Map >> is an access type that points at an incomplete type, where the completion >> follows the instantiation of the Maps generic? > > Bleech. Using access types means that you have to handle the memory > management, defeating the #1 value of the containers. Except that in Ada we cannot access container elements for update without access types or other helper types. Nastiness of the later raises exponentially with every bit of safety added in order to prevent the mess of the former. > To answer the OPs question, a symbol table for a language like Ada is a > multiway tree. That's one reason I pushed for a multiway tree container in > Ada, as it seems to be a common data structure. So I'd use a multiway tree > as the basic structure. Identifier lookups would use a map (as you noted), > and the things that each identifier points at is a list of the symbol table > nodes associated with that identifier. So the lookup data is a map of lists > of tree cursors. Hiding then is dealt with by checking the relationship of > the nodes, or possibly by maintaining a visibility flag in the symbol > records. Looks complicated and inefficient to me. The structure should support group insertion or removal of submaps (e.g. a scope) into the current map. > Note that for Ada, one does not prune the lists of identifiers immediately; > that's the job of the resolver mechanism (because of homographs). The above > is essentially how Janus/Ada deals with the symboltable (using access types > since there were no containers in 1981!). Dealing with hiding isn't pretty > and I don't think there is any way to make it pretty. Perhaps there is > something elegant that can be done for a simpler language, but since there > is only one language that matters, who cares? ;-) and dealing with suggestions and listing conflicting variants should be even less prettier... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de