Re: advice on package design

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> I like the separation very much.

You're not alone.

Part of my reason is that declarations in Ada execute code at run time.
In other languages (e.g. Pascal) there is a strict separation:
declarations declare, statements execute, so it makes sense to have
a syntactic line drawn between the two.  But in Ada, the decls can
do real work, so the line drawn by the "begin" is misleading.
In some cases, the decls do *all* the work, especially when you're
working with Strings, where the length usually depends on the 
initial value.  Then the procedure body says "null;", meaning
"this does nothing", which is a lie.

Sometimes you end up with long chains of deeply nested declare blocks:

    function F(...) return String is
        A: String := ...;
    begin
        Do_Something(A);
        declare
            B: constant String := G(A);    
        begin
            ... and so on ..................................
                                                            declare
                                                                Z: String ...
                                                            begin
                                                                return Z;

Yuck.

Another thing that I trip over once in a while is I want a *statement*
near the beginning of a package body.  It is important that it execute
at the point, because following code (yes, decls are code!) depends
on it.  You can say this:

    package body P is
        package Defeat_Annoying_Syntax_Rules is end;
        package body Defeat_Annoying_Syntax_Rules is
        begin
            Initialize_Database;
        end;

        ... -- 200 lines of code
    end P;

But that seems less readable (to me) than just writing
"Initialize_Database;" where I want it to happen.
So a rule (requiring "declare") that is intended to increase
readability actually decreases it.

And if you want a statement in a package *spec* (say, to initialize
something), it's far worse.  There's no direct workaround; you have to
totally rearrange the structure of your design in order to get around
a silly syntax rule.

It seems to me that:

    Mumble: T := Blah(...);

should be precisely equivalent to:

    Mumble: T;
    Mumble := Blah(...);

which should be precisely equivalent to:

    Mumble: T;
    Blah(Mumble);

(where in the last example we replace function Blah with a procedure
with an 'out' parameter).  The programmer should be able to switch from
one of these forms to another, without changing the semantics of the
program.  But the syntax rules require stirring the code around
when you make these changes.

(Another reason Ada does not have the above desirable property is that
function results of subtype String behave differently from 'out'
parameters of subtype String.  I don't like that.)

> But let's consider getting rid of declarations. Wouldn't it be fake anyway?
> You know that better than me, but I suppose the compiler will need to move
> everything to the beginning of the closest scope. Otherwise:
> 
>    if Halt(x) then
>      declare A;
>    end if;
>    Foo (A); -- Would it be legal?

By "declare A;" I assume you mean something like "A: Integer;".
No, A would not be visible at the call to Foo -- it would be
just like putting a declare block inside the if statement
in the current language.  I'm not proposing anything different
in the semantics, here -- just a minor syntax change.

>    T := (1, 2, 4, declare X := 9, others => declare Y := 10);
>       -- What would be this? How many Y's could be here?

No, I don't propose to allow mixing of decls and expressions!
Just decls and statements.  Decls don't return values.

> So I see no advantage in this.

Convinced?  Partly convinced?  ;-)

- Bob