Re: S-expression I/O in Ada

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

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.

[...]

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

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.

function To_Atom (Object : Arbitrary_Type) return S_Expression.T is
   Blob : Storage_Array (1 .. Object'Size / System.Storage_Unit);
   for Blob'Address use Object'Address;
begin
   return S_Expression.To_Atom (Blob);
end To_Atom;

All this without exposing the internals of an atom.

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 ;/

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

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

This is also the reason why Lists.Vector, in the example above, is
really heterogeneous; it can contain objects of different types that
extend Root.

--
Ludovic Brenta.