Re: S-expression I/O in Ada

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

On 08/12/2010 02:26 AM, Natacha Kerensikova wrote:
>
> There are situations when a memory representation of S-expressions is
> not needed, and the tcp-connect example here seems to be such a case.
> That's why I imagined TCP_Info as a client of Sexp_Stream instead of a
> client of the second package.

Not needed, perhaps, but it makes things clearer and more reusable if it is used 
anyway. The result might not be acceptable for a memory-constrained system, but 
general, reusable pkgs are usually not acceptable when you have special 
requirements.

>> S : S_Expression := Some_Initialization;
>>
>> Put (File =>  F, Expression =>  S);
>
> To achieve such an interface, the client has to build an in-memory S-
> expression object. In the tcp-connect example, there are eight nodes
> (five atoms and three lists). They have to be somehow built, and it
> doesn't look like a simple initialization.

Perhaps not. But for each kind of thing you want to store using this 
representation, it need be done only once, and then reused:

S : S_Expression := To_S_Expression (TCP_Info);

> The second interface I proposed, with a lot of nested calls, builds
> the S-expression object with functions looking like:
> function NewList(Contents, Next: S_node_access) return S_node_access;
> function AtomFromWhatever(Contents: whatever, Next: S_node_access)
> return S_node_access;

An aside on Ada style: Ada is not case sensitive, and many of us reformat code 
to make it easier for us to read. The resulting identifiers such as Newlist and 
Atomfromwidget are not very readable. This is why the convention is to use 
underlines between words.

> For the TCP_info stuff particular case, the only simplification I can
> imagine is leveraging the fact that only 2 among the 8 nodes change.
> So one could construct a global S-expression skeleton with the 6
> constant nodes, and when actually writing data append to the "host"
> and "port" atoms the relevant variable atoms. However that means
> having a read/write global variable, which is bad for tasking, so one
> might prefer a constant 6-node skeleton, duplicated in the declarative
> part of the writing procedure, and then appending the variable nodes.
> However that appending would probably end up with lines like:
> root_sexp.FirstChild.Next.FirstChild.Append(host_node);
> root_Sexp.FirstChild.Next.Next.FirstChild.Append(port_node);
> which looks very ugly to me.

Then I would suggest that your client interface for the TCP-info stuff would 
only deal with (host, port) pairs.

I would suggest a constant in the pkg body that you would use to initialize an 
S-expression variable, then substitute the host and port values into the 
variable before writing. On reading, you would read the S-expression, then 
extract the host and port values and return them to the client.

Ugly is relative; having code like that sprinkled throughout your application is 
ugly; having it occur once in a pkg body is less so. Having it be less ugly and 
occur once in a pkg body would be even better, though.

>> Your TCP_Info-handling pkg would convert the record into an S-expression, and
>> call a single operation from your S-expression pkg to output the S-expression.
>
> That's the tricky part. At least so tricky that I can't imagine how to
> do it properly.

I'm not sure what you think is tricky about it. Clearly you see how to output an 
S-expression:

>> Your S-expression library would implement the writing of the expression as a
>> series of steps.
>
> Indeed, as a series of calls similar to my Sexp_Stream example. I'm
> glad to have at least that part right.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

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