Re: S-expression I/O in Ada

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2010-08-18, Ludovic Brenta <ludovic@ludovic-brenta.org> 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é