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.9 required=5.0 tests=BAYES_00 autolearn=unavailable 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!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Interesting containers problem. Date: Mon, 20 Apr 2015 18:39:54 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <8def4a86-5835-4368-b414-63e12f1074e8@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1429573195 5785 24.196.82.226 (20 Apr 2015 23:39:55 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 20 Apr 2015 23:39:55 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Original Xref: news.eternal-september.org comp.lang.ada:25559 Date: 2015-04-20T18:39:54-05:00 List-Id: "Shark8" wrote in message news:ced95bb5-0bb3-43ee-8d2c-212ea020fd10@googlegroups.com... > On Friday, April 17, 2015 at 2:45:07 PM UTC-6, Randy Brukardt wrote: ... > Ok, I see how a multiway tree maps the structure of nesting scopes... but > maybe I'm >being obtuse here, because I don't see how to access them because there's >no 'key' >type. (Maybe a bit of code would help here.) The keys are into a map of which each element is a list of tree nodes (that is, tree cursors) that have the given identifier. Thus, you have: package Symbol_Tree is new Ada.Containers.Indefinite_Multiway_Trees (Element_Type => Symbol_Root'Class); package Symbol_List is new Ada.Containers.Doubly_Linked_Lists (Element_Type => Symbol_Tree.Cursor); package Identifier_Map is new Ada.Containers.Indefinite_Hashed_Map (Element_Type => Symbol_List.List, Key_Type => String, -- Probably really a UTF8_String, Hash => ..., Equivalent_Keys => ...); I'm too lazy to look up the proper names of the routines to use for the Hash function and the case insensitive equivalency; it's not relevant to the routine anyway. > The way I see it is that the structure we want is essentially a map where > an identifier >is keyed to one of two things: (a) a variable_data, or (b) another >scope-map. -- This >would allow/model nesting. But that doesn't help much (for Ada). In any case, you start with the entire list of declarations with the appropriate identifier and prune out inappropriate kinds of declarations (wrong scope, etc.). The problem is that declarations such as overloaded subprograms don't hide each other unless they're homographs (that is, have the same profile). The identifier alone doesn't tell you much; you have to collect all of the declarations that might be visible. What you are talking about would help in an antique language that doesn't support any overloading, but I would hope that people in this group are beyond that. :-) If anything, Ada doesn't have enough overloading (too much reliance on scopes, something that should have almost no bearing on visibility). Keep in mind that there are many possible queries into a symboltable, and it's never going to be viable to make it easy for all of them. For Ada, you need to look up by identifier, by visibility, by primitive for a given type, and so on. It's not sensible to make it easy to do all of those things. Randy.