Re: S-expression I/O in Ada

[Natacha Kerensikova <lithiumcat@gmail.com>]

On Aug 12, 6:19 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Natacha Kerensikova wrote on comp.lang.ada:
> >> 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.
>
> OK, let's assume this can work technically. Let's do a cost-benefit
> analysis of your preferred solution.

This is turning a bit too much into a childish "my idea is better than
yours" for my taste.

However please note that I'm afraid your misjudging my project by
taking into consideration only what I call Sexp_Stream. I've never
thought Sexp_Stream without the other (still unnamed) package I keep
talking about that handles the representations in memory, because
Sexp_Stream alone won't fit all my needs. These two packages are
functionally equivalent to what I wanted initially, and they are also
equivalent to the package your writing. So from a client point of
view, there wouldn't be much (if any) differences between my second
package and yours. The possibility of using directly Sexp_Stream is
just an option for the particular cases where it is as easy as using
in-memory objects. So I'd say ex-aequo on functionality and
generality.

Now from an implementation point of view, my two-package idea is also
equivalent to my original plans in that the glue between the two
packages is so thin coding both packages takes about as much effort as
my original idea. I suspect your package is very similar to my
original idea, which means ex-eaquo too on implementation efforts and
complexity.

So what are the differences then?

My two-package idea allows to make use of the memory-efficient
Sexp_Stream interface instead of building objects. Honestly I don't
expect ever encountering a situation where it matters, so let's say it
doesn't.

My two-package idea implies a well-defined interface between what
would be two halves of your packages. Well it boils to whether two
independent packages are better or not than a single double-sized
package. I personally have a clear preference of two halves rather
than one equally size; but again, that's just my taste, I'm not sure
there is really any objective technical advantage.

My two-package idea would be implemented under an ISC license, while
your package is GPL. I don't want to start a license troll or
anything, my point here is just that at this point of the analysis
both projects looks so similar to me that license-preferences might be
the only thing left to tip the balance.

My two-package idea is so far just an idea. Your package already has
lots of real code. I won't be surprised if I'm so busy here learning
about what people think about my ideas and learning about Ada that you
end up finishing your package before I actually write my first line in
Ada. We've got a clear winner here.

Thanks for your attention,
Natacha