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!s9g2000yqd.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 10:17:43 -0700 (PDT) Organization: http://groups.google.com 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> <8f4b65ed-e003-4ed9-8118-da8d240dd8aa@z28g2000yqh.googlegroups.com> <6a5068d7-b774-4c52-8b00-ddcc76865847@p7g2000yqa.googlegroups.com> <0cff56bc-32fc-44fe-9e29-9387a4eb4588@l14g2000yql.googlegroups.com> <7990e251-0a92-4790-a24e-0c1899e9295c@a36g2000yqc.googlegroups.com> <8e7cb956-6d25-46c2-a855-a48673b4ee5e@5g2000yqz.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 1281633465 22000 127.0.0.1 (12 Aug 2010 17:17:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 12 Aug 2010 17:17:45 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s9g2000yqd.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:13183 Date: 2010-08-12T10:17:43-07:00 List-Id: On Aug 12, 6:19=A0pm, Ludovic Brenta wrote: > Natacha Kerensikova wrote on comp.lang.ada: > >> 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. > > OK, let's assume this can work technically. Let's do a cost-benefit > analysis of your preferred solution. This is turning a bit too much into a childish "my idea is better than yours" for my taste. However please note that I'm afraid your misjudging my project by taking into consideration only what I call Sexp_Stream. I've never thought Sexp_Stream without the other (still unnamed) package I keep talking about that handles the representations in memory, because Sexp_Stream alone won't fit all my needs. These two packages are functionally equivalent to what I wanted initially, and they are also equivalent to the package your writing. So from a client point of view, there wouldn't be much (if any) differences between my second package and yours. The possibility of using directly Sexp_Stream is just an option for the particular cases where it is as easy as using in-memory objects. So I'd say ex-aequo on functionality and generality. Now from an implementation point of view, my two-package idea is also equivalent to my original plans in that the glue between the two packages is so thin coding both packages takes about as much effort as my original idea. I suspect your package is very similar to my original idea, which means ex-eaquo too on implementation efforts and complexity. So what are the differences then? My two-package idea allows to make use of the memory-efficient Sexp_Stream interface instead of building objects. Honestly I don't expect ever encountering a situation where it matters, so let's say it doesn't. My two-package idea implies a well-defined interface between what would be two halves of your packages. Well it boils to whether two independent packages are better or not than a single double-sized package. I personally have a clear preference of two halves rather than one equally size; but again, that's just my taste, I'm not sure there is really any objective technical advantage. My two-package idea would be implemented under an ISC license, while your package is GPL. I don't want to start a license troll or anything, my point here is just that at this point of the analysis both projects looks so similar to me that license-preferences might be the only thing left to tip the balance. My two-package idea is so far just an idea. Your package already has lots of real code. I won't be surprised if I'm so busy here learning about what people think about my ideas and learning about Ada that you end up finishing your package before I actually write my first line in Ada. We've got a clear winner here. Thanks for your attention, Natacha