Re: advice on package design

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

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

> 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? (:-))

The problem is that whether something goes above or below the "begin"
depends on all kinds of extraneous factors.  If I want to initialize a
variable with a function, it goes above the line.  If I want to use
a procedure call, or a loop, it goes below the line.  Etc.

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

It doesn't seem similar to me.  Here, we are explicitly saying that the
"then" part does nothing, and that's a good thing.  (Some other
languages are more error prone in this regard.)  But a procedure that
does a lot of work that happens to be above the "begin" still needs
"null", which seems sort of silly.

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

I would prefer a separate try/catch-like statement for exception
handling.  Exception handling seems totally unrelated to declaring
things, so I don't see why they should be mixed in the same syntax.
Yes, exception handling requires indentation levels -- seems OK to me.

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

OK, I take it back.  You're right.  I do not want default-initialization
to happen if there's an explicit initialization.

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

Yes.

>... 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! (:-))

I don't know how a language standard can *force* things like that.

> 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? (:-))

A small fraction of one page.  ;-)
Any statement list should act as a scope.

> >>    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?
                                ^^^^^^^^^^^^
You mean expressions?  You can't put statements (or declarations) among
expressions because the type is wrong -- a statement does not return a
value of the right type (it doesn't return a value at all, or in C
terminology, it returns "void".)

> >> So I see no advantage in this.
> > 
> > Convinced?  Partly convinced?  ;-)
> 
> I see the rationale and the problem, but the solution ...

Fair enough.

- Bob