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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Fri, 4 May 2018 17:30:13 -0500 Organization: JSA Research & Innovation Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87k1su7nag.fsf@nightsong.com> <87po2la2qt.fsf@nightsong.com><87in8buttb.fsf@jacob-sparre.dk> <87wowqpowu.fsf@nightsong.com><16406268-83df-4564-8855-9bd0fe9caac0@googlegroups.com><87o9i2pkcr.fsf@nightsong.com> <87in88m43h.fsf@nightsong.com><87efiuope8.fsf@nightsong.com><322f9b26-01de-4753-bb50-6ef2f3d993d8@googlegroups.com><87a7th9pd1.fsf@nightsong.com><87h8no1nli.fsf@nightsong.com> <874ljo1hvy.fsf@nightsong.com> <87vac4z2lh.fsf@nightsong.com> Injection-Date: Fri, 4 May 2018 22:30:14 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="2821"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:51992 Date: 2018-05-04T17:30:13-05:00 List-Id: "Paul Rubin" wrote in message news:87vac4z2lh.fsf@nightsong.com... > "Randy Brukardt" writes: >> All of the Ada containers have "cursors", which serve the reference >> function. You need something like that to specify where to insert >> something >> in a tree ("insert_child (tree, parent)" - the parent is represented by a >> cursor). > > Ok, but can you insert the same child tree into multiple places in the > parent? No, of course not. Because if you could, you'd no longer have a tree. If you have shared nodes, then you have a DAG (directed acyclic graph). We talked about but ultimately decided not to have a graph container, mainly because it is hard to describe how many of the operations would work, particularly the iterators. (The iterators have to be able to visit *all* of the nodes exactly once in some defined order.) A DAG or worse yet, an unstructured graph with circularities, is precisely the kind of thing I was thinking of when I was talking about "spaghetti data". Data structures should be - ahem - structured! Perhaps they might have some weak references (like a cursor) into them, but hopefully not. ... > What if you want one of the elements of a tree node to be a pointer to > its parent? That's a basic part of the tree data structure, every node has a Parent operation. ... > So that's a natural source of circular structure in data. Nope. You are confusing the references needed to construct a data structure with the much weaker ones needed to navigate it. Just because there is a mechanism to find the parent doesn't make the structure circular. Note that as a container, all of the operations on the container keep it properly consistent, so if a node is deleted, the parent pointers and the like are updated. You (the user of the tree container) do not have to do any of this bookkeeping, and you don't have to worry about a broken tree, either. When one builds their own data structures from scratch, one has to worry about (accidentally or on purpose) making circularities, about maintaining the structure's invariants, as well as memory management. GC might help with the memory management end, but a better solution is to let the compiler/runtime deal with the entire set of issues by using a pre-made data structure. (And you get better syntax and capabilities with the pre-made structure, including iterators and (in Ada 2020) aggregates.) ... >> Depends on the job, of course. Much of my software indeed works that way, >> because there is much less security issues with compiled-in settings. > > There is something to be said for that, but I've still been taught that > a principle of configuration management (CM) is to keep stuff like > compilers away from the system as much as you can, so who knows. Depends on the audience, surely. In programs that I expected to be used by less-technical others, one has to provide configuration through a GUI, which means that one has to write the GUI, read the results in the main server, be prepared to change the configuration on the fly, deal with the tasking issues that occur when using variables that might change, etc. A whole heck of a lot more work than declaring ... package AS_Params is Root_Path : constant String := "D:\Webroot\"; ... end As_Params; This puts the configuration into a single Ada package, so it's not distributed everywhere (THAT would be bad). It's easy to find if something needs to be changed, and I'm not afraid of compilers (I write 'em as part of my living! :-). > In the > case of the corporate jargon generator though, I'd consider the phrase > lists to be data rather than settings. So having them compiled into the > program still seems awfully primitive. See above. I'd probably put all of the phrases into a giant aggregate in a configuration package. If someone more ambitious than me wanted to make the GUI and other changes necessary to make the things changable on the fly, they could do so without altering the rest of the program. Randy.