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!uucp.gnuu.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> <1d0e316ux5h5u$.46x8kqxg4u3t$.dlg@40tude.net> <1ffju2fe4dqmz$.10w4bxtx2kvs6$.dlg@40tude.net> Date: Tue, 22 Mar 2005 11:55:33 +0100 Message-ID: <1kich8uln1g7b$.pbxdsgst5s17$.dlg@40tude.net> NNTP-Posting-Date: 22 Mar 2005 11:55:31 MET NNTP-Posting-Host: eb50e684.newsread2.arcor-online.net X-Trace: DXC=S5TGU9CcPCnGnN95NbAh:aQ5U85hF6f;djW\KbG]kaMh]kI_X=5KeafWD@\X=_oN[d[6LHn;2LCVnCOgUkn_?_Yoi7m9b:Slmjo X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:9718 Date: 2005-03-22T11:55:31+01:00 List-Id: On 21 Mar 2005 15:35:36 -0500, Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> The effects of the declaration of an initialized variable and of a >> procedure call are fundamentally different. The first creates a new object >> for following scope. Evaluation of that object is rather a side effect. All >> things visible within the scope should be elaborated before "begin". > > Well, I've considered a language design in which initialization (or > should it be called "creation") is allowed to happen after the > declaration. In this language, initialization has a different syntax > than assignment (":=" for init, ":==" for assignment, or some such). > > So you could do: > > procedure P is > X: T'Class; -- perhaps some syntax saying "do not default init". > > if ... then > X := ...; > else > X := ...; > end if; > ... What about singleton functions? procedure P is X : T'Class is begin if ... then return ...; else return ...; end if; end X; equivalent to: function return T'Class is begin if ... then return ...; else return ...; end if; end ; X : T'Class := ; > You can do that in Ada, but you have to introduce pointers, > and you don't always want pointer semantics. > > I would have compile-time rules that ensure an object is initialized > (created?) before being used or assigned; the compiler would have to do > a bit of flow analysis to check these rules. > > If you do *that*, then an 'out' parameter can either assign into the > actual, or initialize the actual. Programmer's choice. Hmm, lazy parameters, could they do the trick? You pass an out parameter as lazy. The compiler skips any construction until first use in the body. So construction vs. assignment would be controlled on the caller's side. >>... What >> if I rename "declare" to "require", i.e. consider the declaration block as >> a precondition for following "begin". Will it look logical then? >> >> require >> X : T := ...; >> begin >> -- do something with X >> end; -- ensure that there is no X anymore > > Sorry, I guess this is a matter of taste, and my taste says I don't like > the extra verbiage required just to declare X. > > Note that I'm not against block statements. I would allow: > > procedure P is > begin > X: ...; > Y: ...; > > some statements > end; > begin > -- X and Y not visible here. > A: ...; > B: ...; > > some statements > end; > end P; > > or something like that. In two steps away from curly brackets!... (:-)) >>> (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 agree. But I think that the solution is a better balance between effects >> and side effects. >> >> I'd like to think of declarations as things done in parallel as opposed to >> serialized statements. Unfortunately this is also untrue in Ada. >> Serialization is extra coupling, I just feel that something must be wrong >> with that (like that "and" vs. "and then" debate, no good arguments for >> "and", but still...) > > I agree, but I think the same is true of statements. I've thought of > giving the programmer the choice: evaluate a sequence in parallel (and > the compiler checks that there are no bad interactions) or evaluate a > sequence in textual order. Perhaps use "," to separate parallel things, > and ";" to separate sequential things. So: > > X: Integer := 1, > Y: Integer := 2; > Z: Integer := X + Y; > > meaning first create and initialize X and Y in parallel, and then create > and init Z. I believe there was something like that in Occam. However if there are two "gluing operators" ',' and ';' then there must be also order brackets for them. > I agree about the contract. Java does this, but it gets some details > wrong. I want a way to specify defaults. For example, in a real-time > embedded program, I might want to explicitly mark every procedure that > can raise Storage_Error, but in a compiler, that's a waste, since > pretty-much anything can raise S_E. Also, when passing procedures as > parameters, as in iterators, I want a way to say "this thing propagates > whatever the passed procedure propagates". Yes. Some kind of contract algebra is definitely needed. The difficult issue is to get it right for interfaces, overriding, generics. >>...We have to allow user-defined >> operations there. The type developer should be able to specify whether the >> discriminant (constraint) is embedded in each value or not. Then there >> should be a mechanism of constraint propagation like in: >> >> type (Size : Positive) is array (...) of Object (Size); > > Yes, I have similar notions about how compilers should deal with > discrims (stored with objects vs. not stored with objects). > Pragmas seem appropriate here, since it's purely an efficiency choice. > It's like pragma Inline -- sometimes you want it, sometimes you don't > (both for efficiency), but there's no ACATS test that can detect > whether the compiler is obeying your pragmas Inline. Yes, if it does not influence the semantics (pragma's def), then there is no way to detect if the compiler obey it... (:-)) However, for differently constrained subtypes there is a backdoor: T'Size = S'Size. Actually T'Size and X'Size violate a lot of things and should probably be disallowed. On the other hand it could be interesting to allow something like: type T is ...; for T'Class'Size use ; type Array_Of_T is array (...) of T'Class; -- OK because definite type S is new T with ...; -- Compiler checks the size constraint Though size in bits is too low-level and potentially non-portable. There should be a better way... >> BTW, it seems that there is a parallel to if-elsif-elsif-else. What about >> something in this spirit: >> >> declare ... begin >> >> then declare ... begin -- Better keywords needed >> >> then declare ... begin >> >> then declare ... begin >> >> end; >> >> It looks more structured than floating declarations. One could allow it in >> all lists of statements. > > How about if I just promise to leave a blank line between groups of > decls and groups of statements? ;-) I believe you (:-)), but what would you do with: begin Obj1: ...; Obj2: ...; Grind_Upon(Obj1, Obj2); if Halt (x) then goto A; end if; <> Obj3: ...; <> Obj3 := Obj1 + Obj2; Obj3 := Obj3 + 1; if Halt (y) then goto B; end if; end; The above would require multiple construction/destruction of Obj3, stack wind-ups all at run-time etc. > P.S. I suppose the folks who want to talk about Ada on comp.lang.ada (as > opposed to some mythical language that is like Ada, only different) are > rather bored by this discussion. They are busy writing AIs for Ada 2010! (:-)) > But I think language design is fun! Yes -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de