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!h17g2000pri.googlegroups.com!not-for-mail From: Natacha Kerensikova Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Sun, 1 Aug 2010 10:35:17 -0700 (PDT) Organization: http://groups.google.com Message-ID: <8ae8e899-9eef-4c8c-982e-bfdfc10072f1@h17g2000pri.googlegroups.com> References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <1qk2k63kzh7yv$.3jgc403xcqdw$.dlg@40tude.net> NNTP-Posting-Host: 79.82.39.29 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1280684117 3493 127.0.0.1 (1 Aug 2010 17:35:17 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 1 Aug 2010 17:35:17 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h17g2000pri.googlegroups.com; posting-host=79.82.39.29; 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:12779 Date: 2010-08-01T10:35:17-07:00 List-Id: On Aug 1, 2:53=A0pm, "Dmitry A. Kazakov" wrote: > On Sun, 1 Aug 2010 05:17:45 -0700 (PDT), Natacha Kerensikova wrote: > > To describe briefly S-expressions, I consider them to be the simplest > > existing data organization beyond raw sequences of bits. They are > > basically lists of elements, each element being either a list or an > > atom, and atoms being raw sequences of bits. > > So, it is a tree? Yes, it can be thought of as a binary tree whose leaves are labeled (the atom being the label) and with different semantics for the left and right children. I'm unsure this represent correctly empty lists, but otherwise that's it. > > My question here is about how to represent the atoms in Ada. In C it > > was merely a void pointer and a size, but it seems more difficult in > > Ada because of the strong typing. Because it's up to the application > > to make sense (i.e. type) out of the raw sequences of bits in atoms, > > How can it make sense if the type is unknown? If the type is known, why n= ot > to state it? Actually the type is deduced from the context, e.g. (tcp-connect (host foo.example) (port 80)) We've got here five atoms and three lists, and the application reading as a configuration file would know the atom after "host" is a string to be resolved and the atom after port is a number serialized in a decimal representation. However this serialization of a number is an application choice (which I usually choose to make S-expressions text files) but it could have been serialized as a network-ordered 2-byte integer. This means that as far as the S-expression library is concerned, the byte sequence read from the file is not typed. Its typing actually has to be delayed until the application has enough context to interpret it. Hence the need of a typeless chunk of data. > > Though it looks like a fine Ada API (at least to my eyes), I have > > absolutely no idea about how to implement the library. How to define > > the application-opaque Sexp_Atom type? > > It is not clear why do you need such a type. What are the properties of, > and what is it for, given the application need to convert it anyway? Well, I imagined making such a new type to distinguish 'raw data coming from a S-expression to be interpreted' from other raw data types. I thought this was the strong type safety to prevent (de)serialization procedure from trying to interpret just any chunk of memory. > As for raw memory addresses, it is possible to reinterpret them to any > desired type in Ada, as you would do it in C, provided you know what are > you doing. For this you can use so-called address-to-access conversion (s= ee > RM 13.7.2) or placement attribute 'Address (see 13.3(11)). Ok, thanks for this references, I guess I'll find there how many guarantees there are on such raw memory inspection/interpretation. I've already encountered a few situations in C where the code looks very dangerous but where I know perfectly well what I'm doing (I also sort-of expected it would be easier to convince other people I really know what's going on and what I'm doing in such cases when the code is in Ada rather than in C).