Re: S-expression I/O in Ada

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

On 08/18/2010 03:49 AM, Natasha Kerensikova wrote:
>
> 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?

You're mistaken about Doubly_Linked_Lists not doing a deep copy; on the other 
hand, adding an element to a Vector may cause reallocation with an internal 
copy, which lists avoid.

I used Vector here because I thought it would be clearer what is happening, 
since it's an unbounded array. Iteration thus uses "for" loops and indexing to 
access the elements, similar to arrays; I thought this would be clearer to a 
beginner (in Ada). Lists and arrays are both sequences and do the same things, 
so either could be used.

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

OK, I misunderstood that bit. Making the definition of Atom public would be 
fine, then, allowing clients to create their own. You could also replace the 
definition of Atom with

subtype Atom is Byte_Lists.Vector;

which would simplify the implementation a bit.

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

Yes, ideally we want a list of S_Expression. However, the language doesn't allow 
us to create that directly. I can't instantiate Vectors with S_Expression before 
I declare S_Expression, and I can't declare S_Expression until I've instantiated 
Vectors for lists.

But I can instantiate Indefinite_Vectors for Root'Class, then derive 
S_Expression from Root and store S_Expression in the Vector.

Root'Class is indefinite; you can't declare

V : Root'Class;

S_Expression is also indefinite, because tagged types can't have a default on 
their discriminants, so you can't declare

V : S_Expression;

If there were a way to instantiate Vectors with S_Expression directly, then I 
could make S_Expression non-tagged, and have a default for the discriminant; 
S_Expression would then be definite.

-- 
Jeff Carter
"There's no messiah here. There's a mess all right, but no messiah."
Monty Python's Life of Brian
84

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---