Re: S-expression I/O in Ada

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

Natasha Kerensikova wrote on comp.lang.ada:
> 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.

No, there are similar differences in complexity in Delete, Insert and
Append (the Vector occasionally has to reallocate its internal storage
and copy all existing elements over; the Doubly_Linked_List not).
Vector provides random access, Doubly_Linked_List does not. So, while
the two interfaces are similar, Vectors and Lists are for different
kinds of problems with different time complexities.

> 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).

>> 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.

Then there is still no problem:

with S_Expression;
procedure Client is
   type Complex_Atom is record ... end record;
   function To_String (A : Complex_Atom) return String is separate;
   -- does the difficult part of the serialization to string
   function To_Atom (A : Complex_Atom) return S_Expression.T is
   begin
      return S_Expression.To_Atom (To_String (A));
   end To_Atom;
begin
   ...
end Client;

Here, the serialization is indeed in the client.

> 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.

I differ. The Ada way is to treat octets as octets (specifically
Storage_Elements or Stream_Elements), and characters as characters
(specifically [[Wide_]Wide_]Character). (I am surprised you should say
that, since in the next paragraph you say that a String should not
contain UTF-8 octets).

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.

> 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:

1) You replace S_Expression.From_String and To_String with
From_Wide_Wide_String and To_Wide_Wide_String, and the value of any
atom with a Wide_Wide_Unbounded_String.
2) In S_Expression.T'Read and 'Write, you convert every
Wide_Wide_Character to and from its UTF-8 octet representation (i.e.
one or more Stream_Elements). Hidden from the client, of course.

Having said that, I'll add that, in almost all cases, you really don't
want Wide_Wide_Strings; it is better to deal with UTF-8-encoded
Strings. OK, not all elements of such a string is a Character, but you
don't generally care; when parsing the external UTF-8 representation,
the only Characters you really care about are '(', ')', '"', '\' and
'' (space) which are all in the 7-bit ASCII range (as are '0' .. '9'
and 'A'.. 'F' if you use hex-encoding of blobs). You treat all other
octets as parts of characters you don't care about and copy them
verbatim into the atoms. Oh, and if you use GtkAda, (or GTK+ in C), it
expects all character strings to be UTF-8 and does not use
[Wide_]Wide_Strings.

I like to define
subtype UTF8_String is String;

to make it clear when a String really contains UTF-8.

--
Ludovic Brenta.