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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,24d7acf9b853aac8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!209.197.12.242.MISMATCH!nx01.iad01.newshosting.com!newshosting.com!198.186.194.249.MISMATCH!news-out.readnews.com!transit3.readnews.com!teleglobe.net!newsgate.cuhk.edu.hk!news.netfront.net!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Tue, 24 Aug 2010 18:56:32 -0700 Organization: Netfront http://www.netfront.net/ Message-ID: References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> NNTP-Posting-Host: 69.177.175.206 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: adenine.netfront.net 1282701394 3791 69.177.175.206 (25 Aug 2010 01:56:34 GMT) X-Complaints-To: news@netfront.net NNTP-Posting-Date: Wed, 25 Aug 2010 01:56:34 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 In-Reply-To: Xref: g2news1.google.com comp.lang.ada:13713 Date: 2010-08-24T18:56:32-07:00 List-Id: On 08/24/2010 04:41 AM, Natasha Kerensikova wrote: > > Does anybody have an idea about how to solve this issue? What issue? You haven't demonstrated that a deep copy is a problem anywhere outside your mind. If you implement this and find that actual use exhausts memory or takes longer than the user is willing to wait (~2 sec) then you have something to worry about. > Another point I discovered while writing this implementation, is that I > end up writing a lot of wrappers over the container's functions. Would > it be possible to somehow define List and Cursors directly as instances > of the container respective types, and to expose directly container's > functions? All this while maintaining the type hiding, I don't want to > expose the container, and just want to specify "I expose this and that > functions" and tell in the body "oh by the way, this and that functions > are just public names of this and that container functions". This way > the code would be lighter but still as flexible (whenever I'm not > satisfied with container functions, or whenever I want to change the > container, I just have to (re)write the publicly exposed functions > without changing the specification). This is called "renaming as body": you implement the declaration with a renames of another subprogram: function F (I : Integer) return Integer; and later package P is new Something (...); function F renames P.F; This requires that both subprograms have the same parameter and result type profile. > I still can't estimate how bad or inelegant > or ugly are explicit access. I guess even in Ada they have some niche > use, and avoiding expensive copy can be one them, right? They are needed to implement things like Ada.Containers.Doubly_Linked_Lists. > Last point, I had trouble finding names. I read the Ada 95 Quality and > Style Guide, and I find it difficult to follow. For example, I was > tempted to call "Atom" the public array representation, the internal > node type, and the function taking a Cursor and returning the public > array representation. I was tempted to call "Node_Type" the public > enumeration type, the function taking a Cursor and returning the type of > the pointed node, and (not in this implementation but in some other > attempts) the internal object discriminant name. One thing about choosing names: the fewer names you have to choose, the less of an issue it is. If you use a Boolean for the discriminant, for example, then you don't need to choose names for the type of the discriminant or its values. Overloading can also help reduce the number of unique names. Your procedures String_To_Atom and Atom_To_String could be named To_Atom and To_String, same as your functions, just as you did later with procedures and functions named Next and Previous for Cursor. A and S are terrible parameter names for these procedures. I would probably use Value and Image, respectively. > package S_Expressions is > > ----------- > -- Types -- > ----------- This is a worthless comment; we can tell that these are type declarations. It's also not a good way to structure your code. Logically related things should be grouped together, not grouped by an incidental relationship such as "these are all types". You might want to group all declarations relating to Atoms, for example, then all relating to Lists, and so on. > type Node_Kind is (Node_Atom, Node_List); These seem backward from an English usage point of view. Both are nodes, so the rest is a modifier that indicates the kind of node. In English, modifiers usually come before the thing they modify, so Atom_Node and List_Node would be more natural. It also puts the important difference between the 2 first, where it is immediately apparent. > procedure String_To_Atom(S : in String; A : out Atom_Data); > procedure Atom_To_String(A : in Atom_Data; S : out String); These are only partly specified. What happens if S'Length /= A'Length? > procedure Counts(sexp : in List; Atom_Count, List_Count : out Count_Type); > function Atom_Count(sexp : in List) return Count_Type; > function List_Count(sexp : in List) return Count_Type; > function Node_Count(sexp : in List) return Count_Type; These are problematical. I'd use Length rather than Node_Count, but I'm not sure what I'd name the others. > > function Is_Atom(Element : in Cursor) return Boolean; > function Is_List(Element : in Cursor) return Boolean; > function Kind_Of(Element : in Cursor) return Node_Kind; Is_* is good, but I'd just use Kind for the 3rd. > function Atom_Size(Element : in Cursor) return Natural; > function Atom_Contents(Element : in Cursor) return Atom_Data; > function Atom_To_String(Element : in Cursor) return String; Again, Length, Contents, and To_String (or Image). What happens if Element isn't an Atom? > procedure Query_List(Element : in Cursor; > Process : not null access procedure > (Sub_Sexp : in List)); > function Sublist_First(Element : in Cursor) return Cursor; > function Sublist_Last(Element : in Cursor) return Cursor; What happens when Element isn't a List? -- Jeff Carter "Help! Help! I'm being repressed!" Monty Python & the Holy Grail 67 --- news://freenews.netfront.net/ - complaints: news@netfront.net ---