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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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 Path: g2news1.google.com!postnews.google.com!t2g2000yqe.googlegroups.com!not-for-mail From: Natacha Kerensikova Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Fri, 13 Aug 2010 02:32:13 -0700 (PDT) Organization: http://groups.google.com Message-ID: <383ec00d-1f62-4d2f-b501-cedaeaa4b3c4@t2g2000yqe.googlegroups.com> 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: 95.152.65.220 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1281691933 30406 127.0.0.1 (13 Aug 2010 09:32:13 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 13 Aug 2010 09:32:13 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: t2g2000yqe.googlegroups.com; posting-host=95.152.65.220; posting-account=aMKgaAoAAAAoW4eaAiNFNP4PjiOifrN6 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.3) Gecko/20100524 Firefox/3.6.3,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:13209 Date: 2010-08-13T02:32:13-07:00 List-Id: On Aug 12, 8:51=A0pm, Jeffrey Carter wrote: > 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. Well indeed, I do consider readability and simplicity (they often come together) as one of the most important criteria when choosing an interface. I think I didn't explained the whole thought process above, my bad. When I wrote this I couldn't think of any way to write clearer or simpler code with any of the two proposed packages (stream or memory based), because of the basic argument that 8 nodes have to be somehow created anyway and couldn't think of any way of doing that except by creating them one by one (be it with a sequence of procedure calls or a bunch of nested function calls). So when complexity and readability are equal, I go for the least amount of dependencies. Of course finding a way to make S-expression building much clearer with a given interface would be a huge argument in favor of the interface, no matter its level. > > 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 :=3D To_S_Expression (TCP_Info); Unless I missed something important, it looks like it only moves the problem around. While a To_S_Expression function does make a TCP_Info'Write simple and one-operation and all, complexity is only transferred to To_S_Expression which will still have to do the dirty job of creating 8 nodes. > > 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 Newli= st and > Atomfromwidget are not very readable. This is why the convention is to us= e > underlines between words. Yes, I have not managed yet to get that habit. I try to use a Underscore_And_Capitalization style (not sure whether it's the usual Ada idiom or not), but sometimes in the heat of action I forgot to do it (funny thing that identifier that slip end up to be camel cased, while my C habit is underscore and lower case). > >> Your TCP_Info-handling pkg would convert the record into an S-expressi= on, and > >> call a single operation from your S-expression pkg to output the S-exp= ression. > > > 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 ou= tput an > S-expression: You're not the only one having trouble understanding that part. I'm not good at expressing myself :-( What I found tricky is the "single operation" part. Building 8 nodes in a single operation does look very difficult, and while Ludovic's trick of building them from an encoded string is nice, it makes we wonder (again) about the point of building a S-expression object before writing it while it's simpler and clearer to write strings containing hand-encoded S-expressions. Thanks for your remarks, Natacha