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!14g2000yqa.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 07:05:38 -0700 (PDT) Organization: http://groups.google.com Message-ID: <34871bf5-5b0f-482e-a22f-62ff694cbfdc@14g2000yqa.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> <5d0747cf-3226-4048-beb4-78b617fc19c9@v15g2000yqe.googlegroups.com> NNTP-Posting-Host: 178.83.214.115 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1281276338 24940 127.0.0.1 (8 Aug 2010 14:05:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 8 Aug 2010 14:05:38 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 14g2000yqa.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:12955 Date: 2010-08-08T07:05:38-07:00 List-Id: On Aug 8, 12:26=A0pm, Simon Wright wrote: > I'd disagree with Jeffrey here. > > Nothing wrong with stating at the bottom! especially when you already > know that the component you're looking at is likely to be useful and to > fit into *your* way of thinking about things. Your plan already has > higher-level abstractions, so that if you get to the next layer up and > want to change your lowest layer (if only for experimentation's sake) > you will be able to do so. Thanks a lot for the support \o/ > Lots of people round here are responsible for component libraries at > various levels of abstraction which they've developed for their own > purposes and then pushed out to the community in the hope they'll help > someone else. I indeed planned to share such a library (assuming I actually write and finish it), should a generous soul accept to review it. However I have long lost the hope of seeing my S-expression stuff used, I guess I can't win against lisp-trauma. > The only caution I'd add is that, at some point, when you're reading an > S-expression from an external file and you expect the next 4 bytes to > contain an integer in binary little-endian format, you're going to have > to trust _something_ to have got it right; if you wrote "*(struct foo > **)((char *)whatever + bar.offset)" in C you will have to write the > equivalent in Ada. Unless you were going to invent a sort of checked > S-expression? (I don't get that impression!) Actually that ugly C expression is not a part of my S-expression code. It's part of a generic self-balancing binary tree interface, supposed to allow any algorithm as a back end. Because algorithms store different data, I can't make assumption about the position of children or balancing data inside the node structure. Therefore I allow the back-end to provide the offset from the node structure where the generic tree code can find stuff it needs. Here "whatever" is a void pointer, pointing to the beginning of the node structure; "bar" is a structure provided by the back-end; char* cast is needed to perform byte-based pointer arithmetic, and then the struct foo** cast back to the real type of the required element. While I know perfectly what I'm doing with this, I guess it's not obvious for the majority of C coders. My hope with Ada is that I wouldn't ever need to write such dubious expressions. In that particular case, I'm working around C's lack of generics, so it shouldn't be a problem to express this in Ada. And should I ever need to write dubious expressions, hope the Ada context would give me the benefit of doubt long enough to have people read the documents or the comments and understand there was no other choice; while in C people wouldn't go further and just label my code and me as ugly and dangerous. Regarding the integer encoded as 4 little-endian bytes, I believe it's pretty safe because S-expression atom are of known length, so if the length is different than 4 bytes I know there is a problem, and otherwise I need other constrains on the integer to know whether it's valid or not. In any case, it doesn't disrupt the reading or interpretation of the S-expression beyond that particular integer value. Thanks again for your support, Natacha