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: Shark8 Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Fri, 13 Aug 2010 08:58:11 -0700 (PDT) Organization: http://groups.google.com Message-ID: <6ce5d855-d8ee-4781-9f6f-426def7e66ef@t2g2000yqe.googlegroups.com> References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <203526c0-f031-4dfe-b3e0-cd5156de14b8@z28g2000yqh.googlegroups.com> <97ddc8e7-8e18-4d07-aaff-534ead00f4b9@d8g2000yqf.googlegroups.com> NNTP-Posting-Host: 174.28.232.29 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1281715091 19037 127.0.0.1 (13 Aug 2010 15:58:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 13 Aug 2010 15:58:11 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: t2g2000yqe.googlegroups.com; posting-host=174.28.232.29; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET CLR 4.0.20506),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:13226 Date: 2010-08-13T08:58:11-07:00 List-Id: On Aug 13, 2:56=A0am, Natacha Kerensikova wrote: > On Aug 13, 1:26=A0am, Shark8 wrote: > > > I took a bit of a stab at writing an SExpression handler, note that > > it's not a parser [text-file -> SExpression] but rather what (I think) > > you were terming in-memory. > > Indeed, that's what my idea of my still-unnamed in-memory S-expression > object package would look like. > > What I find surprising is that you seem to include type information in > the Node type (which actually represent a S-expression atom, while S- > expression nodes usually include lists too). Is it a typical Ada way > of doing it? > > I find it surprising because the underlying S-expression format (as > standardized by Rivest, I know almost nothing about cons pairs or > lisp) cannot encoding that information. I would expect a S-expression > object in memory to reflect only what can be encoded to and decoded > from S-expression files. > > In fact, one can consider S-expressions as a heterogeneous container, > in that each atom can represent an object of any type (while losing > the type information, which has to be retrieved from somewhere else), > in contrast to thing like vectors, whose items are all of the same > type. Does anybody know an example of heterogeneous container in Ada? > I'm not sure how Ada generics can be leveraged in such a case. > > Another interesting point is that you chose arrays to represent S- > expression lists. Your code seems currently unable to represent empty > lists (which are legal at least in Rivest's S-expressions) but I guess > I can't be too difficult to correct. But it raises the question of > array vs linked list for a S-expression object implementation. > > I'm not sure S-expressions would ever be used in a time-critical > application, so the usual argument of cache-friendliness of arrays is > pretty weak here. S-expressions are meant to be used for I/O where the > bottleneck is most likely to be. > > Ada arrays are statically sized, which can be an issue for parsing, > because S-expression format doesn't encode list length, so a list has > to be built by pushing nodes one after the other until encountering > the end-of-list marker. But I think that should be easily worked > around by using vectors for unfinished S-expression lists, and once > the list is completely parsed build the array from the vector, and > reset the vector for further list parsing. > > However for S-expression objects dynamically created into memory, the > static size of arrays might make some operations much less efficient > than with linked lists. > > Any idea I'm missing about this implementation choice? Would it be > worth to try and make such a package generic over the container type > (array vs linked list vs something else?)? > > Thanks for your code example, > Natacha