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!border1.nntp.dca.giganews.com!nntp.giganews.com!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: Thu, 12 Aug 2010 11:51:15 -0700 Organization: Netfront http://www.netfront.net/ Message-ID: References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <87aap6wcdx.fsf@ludovic-brenta.org> <87vd7jliyi.fsf@ludovic-brenta.org> <699464f5-7f04-4ced-bc09-6ffc42c5322a@w30g2000yqw.googlegroups.com> <87ocdbl41u.fsf@ludovic-brenta.org> <318d4041-eb01-4419-ae68-e6f3436c5b66@i31g2000yqm.googlegroups.com> NNTP-Posting-Host: 75.211.85.46 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: adenine.netfront.net 1281639077 61463 75.211.85.46 (12 Aug 2010 18:51:17 GMT) X-Complaints-To: news@netfront.net NNTP-Posting-Date: Thu, 12 Aug 2010 18:51:17 +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: <318d4041-eb01-4419-ae68-e6f3436c5b66@i31g2000yqm.googlegroups.com> Xref: g2news1.google.com comp.lang.ada:13185 Date: 2010-08-12T11:51:15-07:00 List-Id: On 08/12/2010 02:26 AM, Natacha Kerensikova wrote: > > There are situations when a memory representation of S-expressions is > not needed, and the tcp-connect example here seems to be such a case. > That's why I imagined TCP_Info as a client of Sexp_Stream instead of a > client of the second package. Not needed, perhaps, but it makes things clearer and more reusable if it is used anyway. The result might not be acceptable for a memory-constrained system, but general, reusable pkgs are usually not acceptable when you have special requirements. >> S : S_Expression := Some_Initialization; >> >> Put (File => F, Expression => S); > > To achieve such an interface, the client has to build an in-memory S- > expression object. In the tcp-connect example, there are eight nodes > (five atoms and three lists). They have to be somehow built, and it > doesn't look like a simple initialization. Perhaps not. But for each kind of thing you want to store using this representation, it need be done only once, and then reused: S : S_Expression := To_S_Expression (TCP_Info); > The second interface I proposed, with a lot of nested calls, builds > the S-expression object with functions looking like: > function NewList(Contents, Next: S_node_access) return S_node_access; > function AtomFromWhatever(Contents: whatever, Next: S_node_access) > return S_node_access; An aside on Ada style: Ada is not case sensitive, and many of us reformat code to make it easier for us to read. The resulting identifiers such as Newlist and Atomfromwidget are not very readable. This is why the convention is to use underlines between words. > For the TCP_info stuff particular case, the only simplification I can > imagine is leveraging the fact that only 2 among the 8 nodes change. > So one could construct a global S-expression skeleton with the 6 > constant nodes, and when actually writing data append to the "host" > and "port" atoms the relevant variable atoms. However that means > having a read/write global variable, which is bad for tasking, so one > might prefer a constant 6-node skeleton, duplicated in the declarative > part of the writing procedure, and then appending the variable nodes. > However that appending would probably end up with lines like: > root_sexp.FirstChild.Next.FirstChild.Append(host_node); > root_Sexp.FirstChild.Next.Next.FirstChild.Append(port_node); > which looks very ugly to me. Then I would suggest that your client interface for the TCP-info stuff would only deal with (host, port) pairs. I would suggest a constant in the pkg body that you would use to initialize an S-expression variable, then substitute the host and port values into the variable before writing. On reading, you would read the S-expression, then extract the host and port values and return them to the client. Ugly is relative; having code like that sprinkled throughout your application is ugly; having it occur once in a pkg body is less so. Having it be less ugly and occur once in a pkg body would be even better, though. >> Your TCP_Info-handling pkg would convert the record into an S-expression, and >> call a single operation from your S-expression pkg to output the S-expression. > > That's the tricky part. At least so tricky that I can't imagine how to > do it properly. I'm not sure what you think is tricky about it. Clearly you see how to output an S-expression: >> Your S-expression library would implement the writing of the expression as a >> series of steps. > > Indeed, as a series of calls similar to my Sexp_Stream example. I'm > glad to have at least that part right. -- Jeff Carter "What I wouldn't give for a large sock with horse manure in it." Annie Hall 42 --- news://freenews.netfront.net/ - complaints: news@netfront.net ---