comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Interesting containers problem.
Date: Fri, 17 Apr 2015 23:06:38 +0200
Date: 2015-04-17T23:06:38+02:00	[thread overview]
Message-ID: <1uwarjhgizxpn$.yej2gjfg1nhl.dlg@40tude.net> (raw)
In-Reply-To: mgrrci$q6g$1@loke.gir.dk

On Fri, 17 Apr 2015 15:45:05 -0500, Randy Brukardt wrote:

> "Peter Chapin" <PChapin@vtc.vsc.edu> 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

  reply	other threads:[~2015-04-17 21:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17 13:42 Interesting containers problem Shark8
2015-04-17 19:12 ` Peter Chapin
2015-04-17 20:45   ` Randy Brukardt
2015-04-17 21:06     ` Dmitry A. Kazakov [this message]
2015-04-18 17:21     ` Shark8
2015-04-19 17:10       ` brbarkstrom
2015-04-20 23:39       ` Randy Brukardt
2015-04-21  3:05         ` Randy Brukardt
2015-04-21  8:06         ` Dmitry A. Kazakov
2015-04-21  8:28           ` J-P. Rosen
2015-04-21  8:45             ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox