Re: S-expression I/O in Ada

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2010-08-25, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:
> On 8/24/10 1:41 PM, Natasha Kerensikova wrote:
>>
>> Does anybody have an idea about how to solve this issue?
>
> Part of the issue (if it should be one) can be addressed by by
> looking at S-Expressions as the treesthey are.
> To store data, keep the List type, but store objects inside a map.

That's a very interesting idea. I'm not familiar enough with maps to
imagine how to implement this, but I'll study them. Another nice
facility that I had to live without in C.

> If you'd have a package that was build around a list type
> that uses pointers to connect atom nodes and list nodes,
> would you provide subprograms that either insert copies of
> lists or just connect the existing list to the new list?
> If there was only the latter and no copying, clients would
> have to be very careful not to touch the data structures,
> since they are shared between your implementation and the
> client programs.

Actually as an exercise I started writing an access-based version of the
package, and I planned to forbid any direct action of the client to the
data structure.

There is an opaque Container object, which destroys everything it
contains when finalized, and opaque Cursor objects, which are
semantically like access to nodes: many Cursors can refer to the same
Node, and copying a Cursors doesn't copy any data. The only difference
with Ada.Containers is that I need a read-write Cursor for modifications
around that point, but I will probably wrap it into a record to follow
Ada.Containers.

Then the public subprograms only allow to append a new node at the end
of a Cursor-designated list, said node being internally constructed, the
client only provides data to fill it in; and to cut off whatever lies
after a Cursor-designed node, either including or excluding said node.

That sounds limited enough to prevent the client from reaching a
problematic state.


> I'd use a type test here, not 'Tag,
>
>       function Is_Atom(N : in Node'Class) return Boolean is
>       begin
>          --return Ada.Tags."="(N'Tag, Atom'Tag);
>          return N in Atom;
>       end;

I wasn't aware of that kind of tests, it does indeed look much better
than my tag idea.

> The new DbC-like facilities of Ada use identifier Result when
> referring to a function result.  I'd use Result in place of "ret".

Indeed, thanks for the pointer. In a C context "ret" used to be a pretty
long name of a 10-line scoped variable. Bad habits are difficult to get
rid of.

> Just to mention a possibility, a renaming of "ret" might or might
> not clarify its two roles, being both set in Record_Size, and returned.
>
>       function Atom_Size(Element : in Cursor) return Natural is
>          size : Natural;
>          procedure Record_Size(Element : in Node'Class) is
>          begin
>             size := Atom(Element).Size;
>          end Record_Size;
>          ret : Natural renames size;
>       begin
>          Lists.Query_Element(Element.Internal, Record_Size'Access);
>          return ret;
>       end Atom_Size;

Well actually here my tastes would rather go for "return size;" I
typically use "ret" when I have no other more meaningful name for that
object.



Thanks a lot for your remarks,
Natasha