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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.87.MISMATCH!news.astraweb.com!border2.a.newsrouter.astraweb.com!transit4.hitnews.eu!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: S-expression I/O in Ada Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> <7027f0c6-d909-428c-ab8d-6ba1bd7ff4b2@x21g2000yqa.googlegroups.com> Date: Sun, 8 Aug 2010 17:15:10 +0200 Message-ID: <1424bzz54867w.soj1iq72wkwl$.dlg@40tude.net> NNTP-Posting-Date: 08 Aug 2010 17:15:10 CEST NNTP-Posting-Host: ae46e550.newsspool4.arcor-online.net X-Trace: DXC=_S_5bk3^J6VHigV@eW57PQ4IUK On Sun, 8 Aug 2010 06:49:09 -0700 (PDT), Natacha Kerensikova wrote: > On Aug 8, 3:01�pm, "Dmitry A. Kazakov" > wrote: > The more specialized the format, the more assumptions on the contained > data. Right? Yes if the specialization addresses the encoded entities. No if it does the medium. >>> 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. I see. This confuses things even more. Why should I represent anything as a byte sequence? It already is, and in 90% cases I just don't care how the compiler does that. Why to convert byte sequences into other sequences and then into a text file. It just does not make sense to me. Any conversion must be accompanied by moving the thing from one medium to another. Otherwise it is wasting. >> 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? The difference is that Character represents code points and octet does atomic arrays of 8 bits. > 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? That depends on what are you going to do. Storage_Element is a machine-dependent addressable memory unit. Octet is a machine independent presentation layer unit, a thing of 256 independent states. Yes incidentally Character has 256 code points. > Don't you think one should at least have a serious > look at a file before freaking out and calling it unreadable? There are well-known things which do not require reconsidering. Curly or round brackets aren't bad because of they form. They are because of excessive overloading: the closing brackets of a loop, aggregate, block etc are indistinguishable in C. Further in C you have brackets where there none needed and don't have them where they should be. This do apply to LISP and S-expressions. >>> 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". Nope, we certainly know that each TCP connection needs a port. There is nothing to resolve since the notation is not reverse. Parse it top down, it is simple, it is safe, it allows excellent diagnostics, it works. >>> 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 that. >> 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? See above, if you parse top down, you know if you need that object before begin. Then having a bracketed structure, it is trivial to skip the object's description without construction. Just count brackets. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de