Re: S-expression I/O in Ada

[Natacha Kerensikova <lithiumcat@gmail.com>]

On Aug 12, 2:46 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Natacha Kerensikova wrote on comp.lang.ada:
> > So where are the problems with my Sexp_Stream without in memory
> > object? What am I missing?
>
> The "problem" is that, without admitting it, you have reintroduced a
> full S-Expression parser. Most of it is hidden in the Sexp_Stream
> implementation, but it has to be there.

Actually, I *do* admit it. That's even the whole point of Sexp_Stream:
it does the parsing, the whole parsing, and nothing more.

As soon as I realized (thanks to Dmitry) that the parser can be
meaningfully split from everything else (memory management, object
construction, etc), I was seduced by the idea.

> Otherwise, how can the
> Move_Lower, Advance, and Move_Upper operations work, keeping track of
> how many levels deep you are at all times?

In my idea it doesn't keep track of level depth, though if needed (for
example, to assert Move_Lower and Move_Upper are correctly balanced)
it can be easily added, using and integer in the Sexp_Stream object
that is incremented when moving up and decremented when moving down.
That way it can trigger an exception when encountering an unmatched
')' (the other mismatch being already handled by end-of-stream
exception), though I prefer silently dropping them (though it's a
personal preference, it's probably better design to raise the
exception in the library and catch and drop it in the application if
I'm so inclined).

> Note also that your TCP_Info.Read looks quite similar to mine, except
> that mine takes an S-Expression as the input, rather than a stream.
> Afterwards, it traverses the S-Expression using pretty much the same
> algorithm as yours. The S-Expression itself comes from the stream. So,
> the only difference between your concept and my implementation is that
> I expose the S-Expression memory tree and you don't.

Exactly. It's also very similar to my C clients, which all work on in-
memory S-expression objects.

> The reason why I prefer to expose the S-Expression is because, in the
> general (arbitrarily complex) case, you cannot traverse an S-
> Expresssion linearly; you need to traverse it as what it really is, a
> tree. A stream suggests linear traversal only.

Yes, linear traversal only is indeed a limitation of Sexp_Stream.
That's the reason why I had in mind another package of object and
memory handling, which would rely on Sexp_Stream for the parsing.

I prefer (for now) the Sexp_Stream/memory-object split because 1. it
makes thing more modular, which means more possibilities of localized
changes and of implementation overhaul without changing specification,
and 2. in my real-life application the linear traversal is often
enough. Far from always though, especially when one counts cases when
application can traverse linearly but when of the subobjects needs to
store its sub-S-expression in memory.

> > Actually for a very long time I used to write S-expressions to file
> > using only string facilities and a special sx_print_atom() function to
> > handle escaping of unsafe data. By then I would have handled
> > TCP_Info.Write with the following C fragment (sorry I don't know yet
> > how to turn it into Ada, but I'm sure equivalent as simple exists):
>
> > fprintf(outfile, "(tcp-connect\n\t(host ");
> > sx_print_atom(outfile, host);
> > fprintf(outfile, ")\n\t(port %d)\n)\n", port);
>
> Sure, that can also be done just as easily in Ada. You can write S-
> Expressions as easily as any blob or string;

And even nowadays I still wonder, all things considered, whether it
might be the best way of doing it after all.

As far as I know the three lines above is the simplest way of writing
an S-expression, and often have a hard time finding justifications of
using a more complex way. The only added value I found to S-expression
writing facilities over String I/O is ensuring the written S-
expression is actually what I meant, with parenthesis correctly
matching and no stray character or anything messing up the parsing. As
it never happened to me despite my quite heavy use of S-expressions, I
often doubt the necessity of such extra checks, especially compared to
their complexity-cost.

> it is reading them back
> and understanding their structure that is tricky.

I completely agree.


Thanks for your discussion,
Natacha