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!x21g2000yqa.googlegroups.com!not-for-mail From: Natacha Kerensikova Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Sun, 8 Aug 2010 06:49:09 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7027f0c6-d909-428c-ab8d-6ba1bd7ff4b2@x21g2000yqa.googlegroups.com> References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <1qk2k63kzh7yv$.3jgc403xcqdw$.dlg@40tude.net> <8ae8e899-9eef-4c8c-982e-bfdfc10072f1@h17g2000pri.googlegroups.com> <258zlxrv4fn6.1vszho1rtmf48$.dlg@40tude.net> <984db477-973c-4a66-9bf6-e5348c9b95f2@n19g2000prf.googlegroups.com> <46866b8yq8nn$.151lqiwa0y2k6.dlg@40tude.net> <13b07f2c-2f35-43e0-83c5-1b572c65d323@y11g2000yqm.googlegroups.com> <13tpf7ya3evig$.h05p3x08059s$.dlg@40tude.net> <1lhdkikeh2sif.bd3pon3knbv8.dlg@40tude.net> 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 1281275350 15921 127.0.0.1 (8 Aug 2010 13:49:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 8 Aug 2010 13:49:10 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: x21g2000yqa.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:12953 Date: 2010-08-08T06:49:09-07:00 List-Id: On Aug 8, 3:01=A0pm, "Dmitry A. Kazakov" wrote: > And how are you going to make any assumptions at the level of raw bytes? I'm not, hence the byte-sequence being general-purpose using my definition. (However one could split hair by saying that at the level of raw bytes you're making assumptions about the number and endianness of bits in each byte.) S-expressions on the other hand are slightly less general-purpose in that they contain the assumption that data is organized on the leaves of a binary tree. The more specialized the format, the more assumptions on the contained data. Right? > > In the Get procedure from your last post, you don't seem to make that > > much difference between a binary byte and a Character. > > No I do. But you have defined it as a text file. A streamed text file is = a > sequence of Character items. Actually, I didn't. I only defined it as a bunch of byte sequences organized in a certain way. The fact I usually choose a text representation of S-expressions is purely a personal choice (motivated by the power of existing text utilities like grep and sed), but I've never written a S-expression library assuming it will deal with texts. The canonical form of a S- expression, where atoms are embedded verbatim, is as binary as one can get. > > I would seem > > Ada Strings are also very similar to byte sequences/arrays. > > I remember a machine where char was 32-bit long. I've often wanted to get access to one of those PDP with 9-bit bytes, just to further check my C programs. > Byte, octet, character are three different things (and code point is a > fourth). I know very well these differences, except octet vs character, especially considering Ada's definition of a Character. Or is it only that Character is an enumeration while octet is a modular integer? This leads to a question I had in mind since quite early in the thread, should I really use an array of Storage_Element, while S- expression standard considers only sequences of octets? > > I just meant that judging format only from its > > relatively heavy use of parenthesis is about as silly as judging > > skills of a person only from the amount of melanin in their skin. > > The amount of melanin is unrelated to the virtues we count in human being= s. > An excessive need in indistinguishable brackets would definitely reduce > readability. Of course, this the same issue as curly brackets in C. My opinion being that those brackets are not meant to be read by humans, only by the compiler. Indentation is supposed to provide the same information to humans while being ignored by the compiler. I apply the same rule to S-expressions. Don't you think one should at least have a serious look at a file before freaking out and calling it unreadable? > > That's because some atom types are only known after having examined > > other atoms. I you remember my example (tcp-connect (host foo.example) > > (port 80)), here is how would it be interpreted: from the context or > > initial state, we expect a list beginning with a atom which is a > > string describing what to with whatever is after. "tcp-connect" is > > therefore interpreted as a string, from the string value we know the > > following is a list of settings, > > Once you matched "tcp-connect", you know all the types of the following > components. Unfortunately, you know "80" is a 16-bit integer only after having matched "port". > > This is not always the > > case, for example it might be necessary to build an associative array > > from a list of list before being able to know the type of non-head > > atoms, > > What for? Even if such cases might be invented, I see no reason to do tha= t. > It is difficult to parse, it is difficult to read. So why to mess with? For example, you might have a sub-S-expression describing a seldom used object that is expensive to build, wouldn't you want to be sure you actually need it before building it? Thanks for the discussion, Natacha