Re: S-expression I/O in Ada

[Natacha Kerensikova <lithiumcat@gmail.com>]

On Aug 8, 5:24 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> So Ada's overloading rules might be as complicated as the C++
> rules, but Ada _seems_ simpler, because you can safely ignore
> all the details.  Unless you're writing an Ada compiler, of
> course.

I remember I wasn't that happy with C++ overloading, especially
operator overloading. I wrote a 3D vector library only to find out
operator overloading was more obscuring than improving readability,
because too much was happening behind the scenes. So I came back to a
math-assembly-looking sequence of function calls, uglier but easier to
follow and maintain.

> >...learning both Ada and AWS at the same time will
> > probably be way too much.
>
> Well, I'm not sure.  To learn a programming language, you need to
> write programs, and also read programs.  Jeff's point was that
> reading AWS will help you learn Ada, and that's probably true.

For some strange reason it didn't even occurred to be that the advice
included reading AWS source and not only use it as a library. Still,
AWS looks like an overkill for my web needs.

> By the way, I don't see anything fundamentally wrong with
> your s-expression plans, with s-expressions containing
> raw arrays-of-octets

Thanks for the support, that's what I'm about to do, except I'm still
unsure about what array type to use: range octet, modular octet,
Storage_Element, Stream_Element, something else…

> -- especially since you say you
> already have a lot of stuff using s-exprs.  You can layer on
> top of that less-general but more-typed abstractions, probably
> using generics.

Actually I wasn't aware until very recently that the code I usually
put on top of my S-expression parser is indeed called a parser too. So
yeah, basically my S-expression library will be the common core of all
my specialized configuration/template/etc file parsers.


Natacha