Re: S-expression I/O in Ada

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

On 08/24/2010 04:41 AM, Natasha Kerensikova wrote:
>
> Does anybody have an idea about how to solve this issue?

What issue? You haven't demonstrated that a deep copy is a problem anywhere 
outside your mind. If you implement this and find that actual use exhausts 
memory or takes longer than the user is willing to wait (~2 sec) then you have 
something to worry about.

> Another point I discovered while writing this implementation, is that I
> end up writing a lot of wrappers over the container's functions. Would
> it be possible to somehow define List and Cursors directly as instances
> of the container respective types, and to expose directly container's
> functions? All this while maintaining the type hiding, I don't want to
> expose the container, and just want to specify "I expose this and that
> functions" and tell in the body "oh by the way, this and that functions
> are just public names of this and that container functions". This way
> the code would be lighter but still as flexible (whenever I'm not
> satisfied with container functions, or whenever I want to change the
> container, I just have to (re)write the publicly exposed functions
> without changing the specification).

This is called "renaming as body": you implement the declaration with a renames 
of another subprogram:

function F (I : Integer) return Integer;

and later

package P is new Something (...);

function F renames P.F;

This requires that both subprograms have the same parameter and result type profile.

> I still can't estimate how bad or inelegant
> or ugly are explicit access. I guess even in Ada they have some niche
> use, and avoiding expensive copy can be one them, right?

They are needed to implement things like Ada.Containers.Doubly_Linked_Lists.

> Last point, I had trouble finding names. I read the Ada 95 Quality and
> Style Guide, and I find it difficult to follow. For example, I was
> tempted to call "Atom" the public array representation, the internal
> node type, and the function taking a Cursor and returning the public
> array representation. I was tempted to call "Node_Type" the public
> enumeration type, the function taking a Cursor and returning the type of
> the pointed node, and (not in this implementation but in some other
> attempts) the internal object discriminant name.

One thing about choosing names: the fewer names you have to choose, the less of 
an issue it is. If you use a Boolean for the discriminant, for example, then you 
don't need to choose names for the type of the discriminant or its values. 
Overloading can also help reduce the number of unique names. Your procedures 
String_To_Atom and Atom_To_String could be named To_Atom and To_String, same as 
your functions, just as you did later with procedures and functions named Next 
and Previous for Cursor.

A and S are terrible parameter names for these procedures. I would probably use 
Value and Image, respectively.

> package S_Expressions is
>
>     -----------
>     -- Types --
>     -----------

This is a worthless comment; we can tell that these are type declarations.

It's also not a good way to structure your code. Logically related things should 
be grouped together, not grouped by an incidental relationship such as "these 
are all types". You might want to group all declarations relating to Atoms, for 
example, then all relating to Lists, and so on.

>     type Node_Kind is (Node_Atom, Node_List);

These seem backward from an English usage point of view. Both are nodes, so the 
rest is a modifier that indicates the kind of node. In English, modifiers 
usually come before the thing they modify, so Atom_Node and List_Node would be 
more natural. It also puts the important difference between the 2 first, where 
it is immediately apparent.

>     procedure String_To_Atom(S : in String; A : out Atom_Data);
>     procedure Atom_To_String(A : in Atom_Data; S : out String);

These are only partly specified. What happens if S'Length /= A'Length?

>     procedure Counts(sexp : in List; Atom_Count, List_Count : out Count_Type);
>     function Atom_Count(sexp : in List) return Count_Type;
>     function List_Count(sexp : in List) return Count_Type;
>     function Node_Count(sexp : in List) return Count_Type;

These are problematical. I'd use Length rather than Node_Count, but I'm not sure 
what I'd name the others.

>
>     function Is_Atom(Element : in Cursor) return Boolean;
>     function Is_List(Element : in Cursor) return Boolean;
>     function Kind_Of(Element : in Cursor) return Node_Kind;

Is_* is good, but I'd just use Kind for the 3rd.

>     function Atom_Size(Element : in Cursor) return Natural;
>     function Atom_Contents(Element : in Cursor) return Atom_Data;
>     function Atom_To_String(Element : in Cursor) return String;

Again, Length, Contents, and To_String (or Image). What happens if Element isn't 
an Atom?

>     procedure Query_List(Element : in Cursor;
>                          Process : not null access procedure
>                                         (Sub_Sexp : in List));
>     function Sublist_First(Element : in Cursor) return Cursor;
>     function Sublist_Last(Element : in Cursor) return Cursor;

What happens when Element isn't a List?

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

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