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.6 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fed2e7871ca258cd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-15 12:29:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.ems.psu.edu!news.cis.ohio-state.edu!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9vbc89$eb6li$2@ID-25716.news.dfncis.de> <9ve8jn$esilp$1@ID-25716.news.dfncis.de> Subject: Re: List Container Strawman 1.4 Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Sat, 15 Dec 2001 15:29:04 EST Organization: http://www.newsranger.com Date: Sat, 15 Dec 2001 20:29:04 GMT Xref: archiver1.google.com comp.lang.ada:17954 Date: 2001-12-15T20:29:04+00:00 List-Id: In article <9ve8jn$esilp$1@ID-25716.news.dfncis.de>, Nick Roberts says... > >"Ted Dennison" wrote in message >news:z9aN7.41127$xS6.69040@www.newsranger.com... > >> "unbounded" package, I don't think the user should have to worry about >running >> out of resources like iterators. That sort of breaks the whole "unbounded" >> philosophy. > >I've fixed that. For unbounded lists, the user can have up to 255 cursors >(iterators), dynamically allocated, which can be dynamically varied. The >limit of 255 is arbitrary, and could be increased if you think it necessary. I don't think that really addresses the concern, which is that this isn't really an "unbounded" approach. Not that I'm a huge fan of the approach the current strawman uses either. If you've been reading a while, you know I'd lean towards making the users responsible for iterator safety. But the current approach is the only one that we have been able to get general agreement on. If you could convince folks that your (hugely) bounded approach was the way to go, I'd certianly put that in instead. But so far I see absolutely no sign of that happening. Not a single other person has come out in support of it in two weeks, and I see no evidence that this situation would change if we were to delay things another two weeks. >The fact that an array version is included for each operation that has a >secondary data parameter is not just nice, it is necessary for the sake of >efficiency. Consider the extra work done by converting the array to a list, >and then applying that list. That's only an issue if you don't have the Strawman's "Splice" routine. >I'm afraid I've got quite a few comments on your straw man as it is >currently. Here goes. > >[1] I would prefer the name 'Element_Type' to 'Element' for the generic >parameter, since 'Element_Type' is what Ada.Sequential_IO and Ada.Direct_IO >use. My opinion on the stupidity of "_Type" is probably well known by now. If we were trying to emulate either of those packages in other ways, or there was a good case for it possibly causing confusion, then it might be worth using "_Type" regardless. But I don't believe either is the case here. >[2] I would prefer a name other than 'List' for the list type, since 'List' >seems to be such a natural name for parameters and objects of a list type That issue (type vs. object naming guidelines) has been thouroughly discussed already a week and a half ago. General names like "List" are for types, while objects (and parameters) should be named something more specific that designates either exactly what the object is, or what its role in the system is (eg: "Target"). This isn't just some rule I made up. The Ada Quality and Style guide phrases it this way: * Use singular, general nouns as subtype identifiers. (3.2.2 - Subtype Names) * Choose identifiers that describe the object's value during execution. (3.2.3 - Object Names) You seem to worry that this will cause problems, but we already have a package spec and it hasn't caused problems that I can see. I'm thinking we can get by just fine in the body too. Those are the only places it should be an issue, as everywhere else dot notation can be used to disambiguate. >(not necessarily in the list package spec, but elsewhere). If the unbounded >list package is going to be named 'x.Lists.Unbounded', it would seem natural >to use the name 'Unbounded_List' (by analogy to >Ada.Strings.Unbounded.Unbounded_List). I do feel that the need for >consistency outweighs any complaint of wordiness. If folks *really* want that, we can do it. But the current difference is quite conscious. All things being equal, I'm in favor of keeping things consistent as well. But in this case, all things aren't even close to equal. That naming system (repeating the package name in the type name) was a tragic mistake, and I for one am not in favor of spreading the cancer further throughout the standard libraries in the name of consistency. >[3] Why is Element_Array declared with a Natural index subtype? Wouldn't >Positive be more appropriate? An oversight. You are quite correct. I'll fix it. >[4] If you consider their usage, the functions 'To' and 'From' are surely >confusingly named. What is wrong with 'To_List' and 'To_Array' (or similar)? That may be a bit of an issue. I general I think things should be named relative to the package name. If one uses full dot notation, things look great this way. However, in this case it might be a bit obscure without it: Foo_List := To (Foo_Items); and Foo_Items := From (Foo_List) The flip answer to this it to use the package names anyway if it doesn't look clear without them. However, it would perhaps be nice if things aren't quite so obtuse without them. >[5] Analogous to the Ada.Strings.Maps.To_Set function, the function >'Singleton' should be named more like 'To_List' with a parameter named >'Singleton'. I could see it as an overload of the "To" function, or whatever we end up naming it. But its not that big of a deal either way. >[6] I think it would probably (but not necessarily) be better to have the >list exceptions gathered into the x.Lists parent package, so that there is >only one of each exception (rather than one for each instantiation of >x.Lists.[Unb|B]ounded). That's most likely true. When we have more than one package we can do that. >[7] As mentioned, I actually want to remove directional parameters. Instead, >all that is required is a 'smart reverse' operation. This merely switches an >'effective forwardness' flip-flop between actually forward and actually >backward. All the operations must be programmed to behave according to the >effective forwardness (not difficult). I'd like to see this, but I should note that the less state-full calls are, the easier they will be to parralelize. I also get worried whenever I hear anyone use the word "smart" in the context of a computer program. :-) (several other parameter naming issues removed) I'll look into the merits of all these. I don't think we should let parameter names hold up the works at this point though. We'll never get everyone to agree that they are all perfect. >[12] I like the Remove procedure combining retrieval and deletion. This is >an omission from my own proposal. [13] Maybe 'Old_Element' should be >'Old_Item'. ([14] Also, I would prefer the name 'Extract' for the >subprogram.) I think I like that better too. > >Now we come to the vexed issue of iterators. > >[13] I have a problem with passive iterators. Texts say that they should be >provided in addition to active iterators, but I rather feel this is like Frankly I totally agree with you here. I don't like to use them either. But several people here do, and were quite insistent that they need to be in there. Since it doesn't seriously hurt anything to put one in (its not like it has cascading effects throughout the whole package), I can't really see keeping them out just because the two of us don't like to use them. >[14] I feel that the term 'iterator' should be reserved for a construct that >is applicable to all container types (and which is therefore monodirectional Since we don't and won't have such a thing, I don't see the sense in reserving the term for that. >[15] The reason why I made cursors internal to list objects (rather than >providing a separate cursor type) is because an operation on one cursor >(active on a certain list object) must be able to interrogate and possibly >update any other cursors (also active on the same list object). With >separate cursor objects, the only way to do this is for each cursor to >contain a pointer to the list it is active on, and for each list to contain >pointers (perhaps in a linked list) to all the cursors active on it. This That's correct, but what it ultimately requires is that both lists and active iterators be controlled. I can show the implementation in detail, but the work required is roughly equivalent to providing a body for this package, which is what we were discussing doing in the first place. Fine rationale aside, it appears we have already reached a consensus on using the controlled iterator approach. The issue under consideration isn't if someone has another approach which they can argue is better. Clearly you feel you do. The issue is what we can move forward with. The approach you describe is not substantially different from the one you presented 2 weeks ago, and the fact of the matter is that people, for whatever reason, have not been rallying around it. I don't see any hope in the tide turning in its favor if we wait another 2-4 weeks. The strawman has presented 3 different active iterator approaches (each progressively further from my "ideal" btw). The final one seems to be the one people want. I'm not nessecarily any happier about that than you are, but that's the way it has worked out. >[20] What does Splice do? Is it useful? See *waaay* previously. I cribbed it from the STL. Its essential for efficiently putting two lists together. > >[21] Why do you provide list serialisation (stream read and write) >procedures in public, rather than overriding the Read and Write attributes >of the list type in private? I've had problems (of an exact nature that I forget) when they were private. So that's just become my idiom. It could be that the routines could be moved to just inside of the private section without hurting anything. I'll check it out when I get a chance. >Your proposal apparently omits the following vital operations: [22] testing .. I don't personally consider any of this "vital", and much of it can be done just fine with an iterator, along with loads of other stuff you haven't thought of but someone somewhere else considers vital. :-) The exception is "=", which clearly needs to be redefined or removed. The default is going to be nonsense. >[29] Although you have put some documentation into the spec as comments, it >is not quite as clear or complete as would be ideal. I think it might be >helpful if this documentation were separated out into a text (or HTML) file. I agree with this wholeheartedly. I already have one volunteer to work up some documentation. Unfortunately, he prefers to work in Word instead of HTML(yuk). But word is (arguably) better than nothing. :-) You do point out some issues which I think need to be addressed. But the only ones I'd consider major are issues where it appears we already have a fair amount of consensus on. The rest is just naming issues. >Any more thoughts on a (better) name for the project? (Does 'Tenet' tickle >you at all?) Perhaps my tonsils a bit. :-) I'm still stuck on the palindrome issue. Unfortunately, palindromes are one of the tougher word tricks to work out, so there aren't that many to choose from. Since Anna is taken, I'd kind of like "ANA" (if someone can get a decent acronym for it), or "Elle" or "Ele" for personal reasons. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced.