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-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Wed, 18 Aug 2010 10:49:39 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Wed, 18 Aug 2010 10:49:39 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="29865"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18cEWcZFkDh8jlxQZG1aiWB" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:oZG1bmRUibHdym7BpJ57zvstL9A= Xref: g2news1.google.com comp.lang.ada:13476 Date: 2010-08-18T10:49:39+00:00 List-Id: On 2010-08-17, Jeffrey Carter wrote: > It seemed to me that you could implement this without any access types or > values, so I gave it a shot. The following has been compiled: > > private with Ada.Containers.Indefinite_Vectors; > private with Ada.Containers.Vectors; I have indeed forgotten about Ada containers. However after having read A.18.2 and A.18.3, it seems to me that Doubly_Linked_Lists are more appropriate than vectors: the recursive structure of S-expressions can make assignment (i.e. deep copies) quite expensive, and Doubly_Linked_Lists seem designed primarily to avoid copy of contained objects (though I may be mistaken). Usual operations on S-expressions are append and traversal, on which Vectors don't provide a significant improvement (unlike e.g. random access). Does it make sense or am I missing something? Btw reading A.18 I discovered the idea of Cursor types, which I find very nice: I'm used (in C) to hand over Nodes because they also contain enough information to progress in the S-expression structure, but it looks like Cursor would do it in a more Ada-ish way. > generic -- Object_Conversions > type Element (<>) is limited private; > package Object_Conversions is > function To_Atom (Value : in Element) return Atom; > function To_Object (Value : in Atom) return Element; > end Object_Conversions; I'm not fond of that part, because it's actually a memory dump, while atom contents are supposed to be a serialized representation of (atomic) objects. I'm aware that it's best to hide as much as possible about type definitions, but I think in that particular case having Atom definition public is justified. The idea is that my other objects, clients of S_Expressions, will be able to make a S-expression representing themselves. So they will need subprograms to make S-expressions. Complex objects will only have to use the container aspect of S-expressions, assembling S-expression representation provided by their sub-objects. But at some point some objects will be simple enough to be represented as atoms, and knowledge about how to serialize these atomic objects into atom objects can't be part of S_Expressions. Which means S_Expressions has to expose details of atom type. On the other hand, there will be relatively few atomic objects compared to complex objects. Would it possible to hide atom type definition in a subpackage or something, that would only be with'ed in atomic object packages? Maybe something like: private with S_Expressions.Atoms; package S_Expressions is type Atom is private; ... It doesn't seem to work due to a circular dependency. But there anything to do along that line of thoughts? > type Root is tagged null record; > > package Lists is new Ada.Containers.Indefinite_Vectors (Index_Type => > Positive, Element_Type => Root'Class); > > type S_Expression (Is_Atom : Boolean) is new Root with record > case Is_Atom is > when False => > List : Lists.Vector; > when True => > Value : Atom; > end case; > end record; I don't understand why you need Indefinite_Vectors here. They have been presented to me as heterogeneous vector containers, but here Lists would be homogeneous, containing only S_Expression items. I'm not sure about the need of Root either, but my guess is that it's to provide a common root to all objects contained in the Indefinite_Vectors. But what makes S_Expression an indefinite type? Thanks a lot for your review, Natacha