Re: S-expression I/O in Ada

[Natacha Kerensikova <lithiumcat@gmail.com>]

On Aug 13, 1:26 am, Shark8 <onewingedsh...@gmail.com> wrote:
> I took a bit of a stab at writing an SExpression handler, note that
> it's not a parser [text-file -> SExpression] but rather what (I think)
> you were terming in-memory.

Indeed, that's what my idea of my still-unnamed in-memory S-expression
object package would look like.

What I find surprising is that you seem to include type information in
the Node type (which actually represent a S-expression atom, while S-
expression nodes usually include lists too). Is it a typical Ada way
of doing it?

I find it surprising because the underlying S-expression format (as
standardized by Rivest, I know almost nothing about cons pairs or
lisp) cannot encoding that information. I would expect a S-expression
object in memory to reflect only what can be encoded to and decoded
from S-expression files.

In fact, one can consider S-expressions as a heterogeneous container,
in that each atom can represent an object of any type (while losing
the type information, which has to be retrieved from somewhere else),
in contrast to thing like vectors, whose items are all of the same
type. Does anybody know an example of heterogeneous container in Ada?
I'm not sure how Ada generics can be leveraged in such a case.

Another interesting point is that you chose arrays to represent S-
expression lists. Your code seems currently unable to represent empty
lists (which are legal at least in Rivest's S-expressions) but I guess
I can't be too difficult to correct. But it raises the question of
array vs linked list for a S-expression object implementation.

I'm not sure S-expressions would ever be used in a time-critical
application, so the usual argument of cache-friendliness of arrays is
pretty weak here. S-expressions are meant to be used for I/O where the
bottleneck is most likely to be.

Ada arrays are statically sized, which can be an issue for parsing,
because S-expression format doesn't encode list length, so a list has
to be built by pushing nodes one after the other until encountering
the end-of-list marker. But I think that should be easily worked
around by using vectors for unfinished S-expression lists, and once
the list is completely parsed build the array from the vector, and
reset the vector for further list parsing.

However for S-expression objects dynamically created into memory, the
static size of arrays might make some operations much less efficient
than with linked lists.

Any idea I'm missing about this implementation choice? Would it be
worth to try and make such a package generic over the container type
(array vs linked list vs something else?)?


Thanks for your code example,
Natacha