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,UTF8 Path: g2news1.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!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 11:59:13 +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=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 18 Aug 2010 11:59:13 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="13718"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18DQDk+wZ7vpKf6vY+jCeFC" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:Az5fAf1fZW+lU7IcbRwUDGlwVQQ= Xref: g2news1.google.com comp.lang.ada:13479 Date: 2010-08-18T11:59:13+00:00 List-Id: On 2010-08-18, Ludovic Brenta wrote: > Natasha Kerensikova wrote on comp.lang.ada: >> 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). > > I think you are mistaken: > > ARM A.18.3(159/2): > The execution of an assignment_statement for a list shall have the > effect of copying the elements from the source list object to the > target list object. > > However, if the elements contain access values, then whether _they_ > perform a deep or shallow copy is your decision; the Element_Type may > be controlled or not. Actually that's not exactly what I meant. What I meant is that in the usual operations on Vectors (e.g. increasing storage space to complete an Append call) there are more hidden assignments (and therefore, deep copies) than on Doubly_Linked_Lists. But having another look at A.18, it seems I was indeed mistaken. Then I don't really understand the point of having both Vectors and Doubly_Linked_Lists. The interface of Vectors is a strict superset of the interface of Doubly_Linked_Lists, and the only difference in complexity (which is advice anyway, so non-guaranteed) is on Prepend. The only notable difference I've found is that Doubly_Linked_Lists.Cursor is more resistant to container changes than Vectors.Cursor, but I find it a bit weak to justify the existence of both types. What I am missing there? >> 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? > > Yes; in my implementation I resolved that problem by providing a > generic package Serialization containing the To_Atom and From_Atom > operations, for any discrete type. For other, arbitrary types, I > provide From_Blob and To_Blob; a client of my S_Expression package can > thus hex-encode any object by overlaying it with a Storage_Array, e.g. Obviously, discrete type serialization alone is not enough, as I will have non-discrete atomic object to somehow turn into atoms. And your _Blob functions suffer from the same issue as Jeffrey Carter's implementation in that it's just a memory dump. > In my implementation, it is also possible to turn any kind of object > into an atom by providing a pair of To_String, From_String operations, > but these operations actually perform the serialization you were > trying to hide ;/ Actually I'm not trying to hide the serialization, I only want to have it happen in the client object package, because I assume the object is better qualified to know how to serialize itself rather than the S-expression package. I'm aware we don't agree on the S-expression concept, but my (and Rivest's) atoms are only a sequence of octets. In that case From_String and From_Blob actually perform the same operation, which is taking an array of Ada things which are basically (on most platforms) octets, and turn them into the internal Atom type. That's why I'm not at ease with From_String and From_Blob, I feel it should be one function. Let's take for example a Wide_Wide_String (e.g. because that's how my application handles strings internally), which is not so good as an example because a memory dump wouldn't be so much of an issue (except maybe for endianness). Let's further assume I want it serialized in UTF-8. How do I do that? From_String is not good, because Ada Strings are supposed to represent iso-8859-1 code points, which a UTF-8 string is not. From_Blob is not good because the point of using UTF-8 is to still be in a certain text representation, and because it involves turning the Wide_Wide_String into a UTF-8 string type, then into a Storage_Array, then at last into an Atom; while UTF-8 is already supposed be a sequnce-of-octet encoding. See my point? Now of course I could hide Atom type away and allow conversions to and from Storage_Element_Array or Stream_Element_Array, which would amount to a (IMHO useless) direct copy. As I said, I understand the point of hiding type definitions, and the main reason I think it's a valid exception here it that the Atom type is already defined by the S-expression standard I follow, so there is little to no chance of ever having to change it. >> 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? > > The type S_Expression is definite but Root'Class, being class-wide, is > indefinite. (It is considered to have at least one unknown > discriminant, which is the tag). Yes, I understood that (and I was trying in vain to mean that when I explained my perception of Root use). What I don't understand is why using a Root'Class indefinite vector instead of a S_Expression vector? Sorry for my poor expression and thanks for your comments, Natacha Porté