From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,999932ecc319322a X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!newsfeed.stueberl.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: advice on package design Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1110212638.336123.298580@l41g2000cwc.googlegroups.com> <1gbk0qx2sgzpg$.sltzfssofla8$.dlg@40tude.net> <3jok3ghqqls8$.1rrsonb8jsurt$.dlg@40tude.net> <88zllqj1min5$.fqqxis9i327d$.dlg@40tude.net> <18e9a92kz25wu$.8b965bel5vef$.dlg@40tude.net> <1dgodaruwhhwo$.1baazg490isjx.dlg@40tude.net> Date: Fri, 18 Mar 2005 11:00:27 +0100 Message-ID: <1d0e316ux5h5u$.46x8kqxg4u3t$.dlg@40tude.net> NNTP-Posting-Date: 18 Mar 2005 10:56:52 MET NNTP-Posting-Host: 24dd42f4.newsread2.arcor-online.net X-Trace: DXC=]b:`X_hHN<0OjE[7VlJ2<0Q5U85hF6f;4jW\KbG]kaM8liQbn6H@_E91ajCZd1=aL=WRXZ37ga[7:n919Q4_`Vj9B8=X\UUgbk4 X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:9589 Date: 2005-03-18T10:56:52+01:00 List-Id: On 17 Mar 2005 16:26:22 -0500, Robert A Duff wrote: > "Dmitry A. Kazakov" 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