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,CP1252 Path: g2news1.google.com!postnews.google.com!l6g2000yqb.googlegroups.com!not-for-mail From: Natacha Kerensikova Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Sat, 14 Aug 2010 04:02:18 -0700 (PDT) Organization: http://groups.google.com Message-ID: <31c45692-c78f-4b10-b154-e69044863ddc@l6g2000yqb.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> <4b177e75-e387-47ed-b17c-bf1d69b1bc8c@y11g2000yqm.googlegroups.com> NNTP-Posting-Host: 178.83.214.115 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1281783738 16196 127.0.0.1 (14 Aug 2010 11:02:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 14 Aug 2010 11:02:18 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: l6g2000yqb.googlegroups.com; posting-host=178.83.214.115; 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:13276 Date: 2010-08-14T04:02:18-07:00 List-Id: On Aug 13, 11:48=A0pm, Shark8 wrote: > These aren't valid representations of the LISP-like structure -- > Remember that it [a list] is defined as a single item followed my a > list OR a single item alone. Therefore, *all* internal nodes in the > previous drawings should be A-L type and the leaf-nodes should be the > [terminal] A-type node. So you're saying what you call "item" can't be a list? Then you can't make nested lists, right? That sure makes lisp much simpler=85 > > 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'm tempted to say 'yes' but I'm a newcomer to the language (from a > Pascal/Delphi background); so take that with a grain of salt. In my > opinion types are your friends {they give you information about what > your datum/variable *is*} and you shouldn't strip type-information > without good reason. That was my main reasoning for making the node- > type carry information about its contents; you *could* use arrays-of- > bytes/bits but, unless you need to, why? Because the external format defined by the S-expression standard has no room for type information. While you can indeed create typed nodes from in-memory objects, whose type is well known, when you'll have to create a node from a stream/file/whatever following the S-expression standard, you won't have any way to retrieve the type information. > > Ada arrays are statically sized, which can be an issue for parsing, > > because S-expression format doesn't encode list length, > > That can be handled by the parser; after all it has to figure out list > lengths in order to produce the list-object, right? > Using the streams provided is a way to cut out the parser altogether, > if that's an issue, and you can just load the SExpressions directly... Yes but that wouldn't help using existing S-expression files, which is the whole point of my S-expression library project. > > so a list has > > to be built by pushing nodes one after the other until encountering > > the end-of-list marker. > > You're confusing parsing the list with the finished/internal list- > structure itself, I think. > Parsing is just a way of saying "I'm reading this [in order to produce > this structure]." Yes, except "this" has a well-defined on-disk representation, which surely is not the same as any internal in-memory representation of any GCC object. This well-defined on-disk representation happens to give no clue about a list size, so it has to be deduced from the list contents read until the end-of-list marker is reached. Such an on-disk representation means that the in-memory representation used by the parser has to be able to grow on demand. I don't know whether Ada arrays can be tricked into that, but from the little Ada I know vectors are more indicated here. That's what I meant, do you still see any confusion? > > 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. > > I doubt that; like you just mentioned you could wait until the entire > list has been read into-memory before converting it to a static array. Yes, and at that paragraphed I had already moved on to in-memory S- expression creation from nothing, having finished with S-expression reading from parsing a stream (or whatever). Thanks for your help, Natacha