Re: advice on package design

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 17 Mar 2005 16:26:22 -0500, Robert A Duff wrote:

> "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.

Yes, indirectly they do. For the following body this is the code that never
fail. Similarly, each "end;" is in fact also a code which again never fails
(for the body above). I can buy this as modularization (can I sell it so
too? (:-))

> 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.

Yes. A similar case is:

if 0 = Some_Win_API (...) then
   null; -- Don't care about your silly return codes!
end if;

> 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.

I also dislike unnecessary indentations, but what if exception handling is
needed? Then you have to create blocks anyway.

> It seems to me that:
> 
>     Mumble: T := Blah(...);
> 
> should be precisely equivalent to:
> 
>     Mumble: T;
>     Mumble := Blah(...);

So Mumble is first constructed and then assigned? Would you leave that to
the optimizer? I wouldn't. I prefer a clear distinction between ":=" in
declarations (= in-place construction with parameters) and ":=" in the body
(= assignment).

> 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 that will require switching to heap. I would like to leave that all to
the programmer. Let he be able to *easily* create access types acting as
light-weight handles. Then "out" will be just a handle. Why to overload the
compiler with things it cannot do optimal and require from a programmer an
in-depth understanding of what compiler will do IF?

> 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.)

Neither I do. But I think that the difference is rather fundamental. It
appears all over many other places: in object construction, in
discriminated types, in class-wide types etc. For this reason, I would like
to see some general mechanism for evaluation of the constraints
*independently* from the values; and also for forcing the compiler to
evaluate statically known constraints at compile time and to remove them
from all sorts of dopes. So instead of hiding the skeleton in the cupboard
I would openly present it to the public! (:-))

>> 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.

I see. But that will require definition of which parts of which statements
may act as scopes: loop, if alternative, case choice, exception choice
(already so in the "X : others"-kludge), select choice etc. How many pages
of ARM? (:-))

>>    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.

Once you let them in, then: if I can put declarations among statements, why
cannot I put statements among declarations?

>> So I see no advantage in this.
> 
> Convinced?  Partly convinced?  ;-)

I see the rationale and the problem, but the solution ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de