Re: S-expression I/O in Ada

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2010-08-17, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> It seemed to me that you could implement this without any access types or 
> values, so I gave it a shot. The following has been compiled:
>
> private with Ada.Containers.Indefinite_Vectors;
> private with Ada.Containers.Vectors;

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). Usual operations on S-expressions
are append and traversal, on which Vectors don't provide a significant
improvement (unlike e.g. random access).

Does it make sense or am I missing something?

Btw reading A.18 I discovered the idea of Cursor types, which I find
very nice: I'm used (in C) to hand over Nodes because they also contain
enough information to progress in the S-expression structure, but it
looks like Cursor would do it in a more Ada-ish way.

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

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?



Thanks a lot for your review,
Natacha