Re: S-expression I/O in Ada

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Natasha Kerensikova wrote on comp.lang.ada:
>>> 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.
>
>> Why is that a problem? The only reason I can think of is that your
>> type contains access values, in which case it's simply not an atom but
>> rather a cons pair (or a list).
>
> Serialization isn't only about access values. Or maybe I'm misusing the
> word.
>
> Anyway, my (and Rivest's) S-expressions being meant for storage and
> transport, there are other issues with memory dumps than access values.
> For example, endianness, space-efficiency, or human-readability.

Endianness only affects discrete types, which the generic To_Atom and
From_Atom for discrete types convert to textual representation. And my
implementation theoretically also works with multi-byte characters
since it simply calls 'Image and 'Value.

Space efficiency and human readability are antagonistic goals. S-
Expressions are not meant to be space-efficient. If you want space
efficiency, pipe the S-Expressions through zlib :) OTOH, a raw memory
dump is not human-readable, hence the optional hex-encoding.

> Yes, and that's exactly what I would do if I was forced to hide Atom
> type definition; except I wouldn't use String as an intermediate value,
> rather Storage_Element_Array or Stream_Element_Array, because I allow both
> string and binary contents in atoms.
>
> Which then raises the question, why not use array-of-octet directly, to
> avoid issues when Storage_Element or Stream_Element are not octets.

Sure, that's an option. I used Storage_Element but I might as well
have used Interfaces.Unsigned_8.

> But then I could make a public array-of-octets type, and provide
> functions to "convert" back and forth between the private Atom type and
> public array-of-octets type. Would that be acceptable?

Sure. The only problem would be that you probably want the external
representation to be human-readable, so you'd still need some sort of
conversion.

>> Therefore, as String is not a blob. The blob needs to be encoded into
>> ASCII characters, the String does not because it already consists of
>> characters. Therefore From_Blob hex-encodes the blob into a String.
>
> My (and Rivest's) atoms can contain any octet sequence, which makes the
> hex encoding irrelevant. So I do treat strings as blobs, they are both
> data only a type away from being an atom.
>
> You could somehow say that strings and blobs need only to be "cast" into
> an atom, while other objects need to be serialized first (usually into
> strings or machine-independant blobs).

OK. I was working under the assumption that S-Expression files must be
human-readable and only contain ASCII or UTF-8 in order to work with
any text editor. But if you lift that assumption, then your solution
works.

>>> 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?
>>
>> By modifying my implementation a little:
>
> I think you're missing the point. I don't want to modify any
> s-expression package implementation whenever I use a new type in an
> application.

Ah but the fact that you changed the application-level type is
irrelevant. The relevant fact was that you changed the external
encoding, which is hidden in the body of the S_Expression package, to
UTF-8 (and which simply does not exist in your implementation). But I
see your point.

> Let's say for example I have a thousand of applications using Strings,
> and one using Wide_Wide_Strings, I can't see how it can be justified to
> change (or fork) the S-expression package to take it into account.

No, but you could hex-encode the Wide_Wide_String instead of using
UTF-8 in that one package. Or, for an alternative, see below...

> It seems much more natural, at least to my C-used eyes, to ask that one
> application to provide whatever is needed to serialize Wide_Wide_Strings
> into atoms.

i.e.
subtype UTF8_String is String;
function To_UTF8 (S : Wide_Wide_String) return UTF8_String;
function To_Atom (S : Wide_Wide_String) return S_Expression.T is
begin
   return To_Atom (To_UTF8 (S));
end To_Atom;

?

which is a specialization of the example I used to demonstrate that
you can move the serialization of any arbitrary type into the client
if that's what you need.

--
Ludovic Brenta.