Re: S-expression I/O in Ada

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2010-08-27, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
> On 27.08.10 15:19, Natasha Kerensikova wrote:
>> Hello,
>> 
>> Here is my third attempt, hopefully avoiding the mistakes I did before.
>
> Just a few quick comments on style, more or less.
>
> The first is to use -gnatwa every now and then, or a similar
> feature of your Ada compiler or analysis tool.  It will tell
> you which variables are in effect constants, for example.

Actually in C I'm used to always compile with the maximum level of
warning (pedantic) and treat them as errors. I didn't do that because I
had not found the documentation of my compiler (fsf gnat 4.4 from
FreeBSD port tree).

So I guess that would be "-gnatwae -gnaty" (I do like the idea of style
checks too). But this raises the question, what is the rationale for
excluding some warning from -gnatwa? I'm also curious about excluded
style checks. Would anybody happen to know where I can find such
rationale? Google doesn't seem very helpful, but I'm not convinced by my
keyword choice either.

By the way, about style issues, do you all here really use the
"standard" (or so it seems to me) indentation of 3 spaces for new blocs
and 2 spaces for line continuations? This is still way too shallow for my
tastes.

The reason why I'm so keen on getting whatever messages the compiler can
provide is that they might be helpful indication of a programming error
that results in a syntactically correct code. For example here, -gnatwa
complains about Current not being constant, but it's not supposed to be,
as it's a pointer to the node being currently processed in a iterator.
So this warning reveals that I have actually forgot to increment Current
(hence never write it), which ends up in an infinite loop.

I find compiler issues to be the weakest point of Ada: documentation is
pretty well hidden, installation is a mess, and there is that
project-file stuff which seems almost as complicated as Ada language
itself, while being compiler-dependant. Coming for a C world where
everything is simpler and well documented in manual pages...

> Second, if you assign entire aggregates instead of performing
> several assignment component by component, this ensures you
> will never miss a component, should the definition of the
> type change.

I didn't know about this syntax, but it does look very seducing. Thanks
a lot for pointing it out.

> Finally, some variables (like First in Iterate_Over_Lists)
> may or may not serve some purpose, and can be omitted.
> OTOH, I guess one might want to weigh this against having
> a meaningful name for a larger construct or consider a
> more locally declared constant instead (in a declare block).

Well actually it doesn't serve any purpose, I used such a variable
because I wasn't aware a record could be created anonymously.
Considering the parameter of the callback is also named First, there is
not additional information for the human reader by using an
intermediate.

Even

function Root(From : in Container) return Cursor is
   Result : constant Cursor := (Parent => null, Node => From.Root);
begin
   return Result;
end Root;

wouldn't be simpler and clearer to build the Cursor anonymously:

function Root(From : in Container) return Cursor is
begin
   return Cursor'(Parent => null, Node => From.Root);
end Root;

Or am I confusing terseness with simplicity?



Thanks a lot for your remarks,
Natasha