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!news2.google.com!postnews.google.com!a36g2000yqc.googlegroups.com!not-for-mail From: Natacha Kerensikova Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Thu, 12 Aug 2010 06:23:34 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7990e251-0a92-4790-a24e-0c1899e9295c@a36g2000yqc.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> <8f4b65ed-e003-4ed9-8118-da8d240dd8aa@z28g2000yqh.googlegroups.com> <6a5068d7-b774-4c52-8b00-ddcc76865847@p7g2000yqa.googlegroups.com> <0cff56bc-32fc-44fe-9e29-9387a4eb4588@l14g2000yql.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 1281619415 7844 127.0.0.1 (12 Aug 2010 13:23:35 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 12 Aug 2010 13:23:35 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: a36g2000yqc.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:13175 Date: 2010-08-12T06:23:34-07:00 List-Id: On Aug 12, 2:46=A0pm, Ludovic Brenta wrote: > Natacha Kerensikova wrote on comp.lang.ada: > > So where are the problems with my Sexp_Stream without in memory > > object? What am I missing? > > The "problem" is that, without admitting it, you have reintroduced a > full S-Expression parser. Most of it is hidden in the Sexp_Stream > implementation, but it has to be there. Actually, I *do* admit it. That's even the whole point of Sexp_Stream: it does the parsing, the whole parsing, and nothing more. As soon as I realized (thanks to Dmitry) that the parser can be meaningfully split from everything else (memory management, object construction, etc), I was seduced by the idea. > Otherwise, how can the > Move_Lower, Advance, and Move_Upper operations work, keeping track of > how many levels deep you are at all times? In my idea it doesn't keep track of level depth, though if needed (for example, to assert Move_Lower and Move_Upper are correctly balanced) it can be easily added, using and integer in the Sexp_Stream object that is incremented when moving up and decremented when moving down. That way it can trigger an exception when encountering an unmatched ')' (the other mismatch being already handled by end-of-stream exception), though I prefer silently dropping them (though it's a personal preference, it's probably better design to raise the exception in the library and catch and drop it in the application if I'm so inclined). > Note also that your TCP_Info.Read looks quite similar to mine, except > that mine takes an S-Expression as the input, rather than a stream. > Afterwards, it traverses the S-Expression using pretty much the same > algorithm as yours. The S-Expression itself comes from the stream. So, > the only difference between your concept and my implementation is that > I expose the S-Expression memory tree and you don't. Exactly. It's also very similar to my C clients, which all work on in- memory S-expression objects. > The reason why I prefer to expose the S-Expression is because, in the > general (arbitrarily complex) case, you cannot traverse an S- > Expresssion linearly; you need to traverse it as what it really is, a > tree. A stream suggests linear traversal only. Yes, linear traversal only is indeed a limitation of Sexp_Stream. That's the reason why I had in mind another package of object and memory handling, which would rely on Sexp_Stream for the parsing. I prefer (for now) the Sexp_Stream/memory-object split because 1. it makes thing more modular, which means more possibilities of localized changes and of implementation overhaul without changing specification, and 2. in my real-life application the linear traversal is often enough. Far from always though, especially when one counts cases when application can traverse linearly but when of the subobjects needs to store its sub-S-expression in memory. > > Actually for a very long time I used to write S-expressions to file > > using only string facilities and a special sx_print_atom() function to > > handle escaping of unsafe data. By then I would have handled > > TCP_Info.Write with the following C fragment (sorry I don't know yet > > how to turn it into Ada, but I'm sure equivalent as simple exists): > > > fprintf(outfile, "(tcp-connect\n\t(host "); > > sx_print_atom(outfile, host); > > fprintf(outfile, ")\n\t(port %d)\n)\n", port); > > Sure, that can also be done just as easily in Ada. You can write S- > Expressions as easily as any blob or string; And even nowadays I still wonder, all things considered, whether it might be the best way of doing it after all. As far as I know the three lines above is the simplest way of writing an S-expression, and often have a hard time finding justifications of using a more complex way. The only added value I found to S-expression writing facilities over String I/O is ensuring the written S- expression is actually what I meant, with parenthesis correctly matching and no stray character or anything messing up the parsing. As it never happened to me despite my quite heavy use of S-expressions, I often doubt the necessity of such extra checks, especially compared to their complexity-cost. > it is reading them back > and understanding their structure that is tricky. I completely agree. Thanks for your discussion, Natacha