Operation can be dispatching in only one type
in [ADA]
|
From: Georg Bauhaus on 2 Dec 2009 10:35 Jean-Pierre Rosen schrieb: > Note that if the Java > people were confident in their rule, there would be no need to require > that every variable be initialized to zero! A local variable, unlike the others, is not initialized to zero. But the "assigned before use" rule applies to local variables.
From: Randy Brukardt on 3 Dec 2009 00:23 "John B. Matthews" <nospam(a)nospam.invalid> wrote in message news:nospam-9C9974.07353802122009(a)news.aioe.org... .... > I'm not especially advocating applying the Java rules to Ada, but I like > the warning. Warnings have no semantic impact in Ada. There are a few places in the standard that suggest that warnings be generated, but there is no ideas whatsoever what that might mean. It is purely a quality-of-implementation issue -- and that is between you and your Ada vendor. Randy.
From: Randy Brukardt on 3 Dec 2009 00:29 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:1jcbtmi5rztyp$.norvlhez9i9$.dlg(a)40tude.net... .... > No the problem is whether to treat a call to the body as legal. The > problem > is that you could not rely on its contract (out Car), in order to be able > to decide whether this call would "initialize" the object. > > BTW, you consider ":=" as an initialization, but why? Where is a guaranty > that it initializes the object by a "valid" value? I feel that very > concept > is somewhat inconsistent with ADT. To expand on this point, there are a number of places in Ada where objects can become "deinitialized". (Compilation strategies can prevent some of these, but at a cost of more checks with the associated loss of performance. For instance, Janus/Ada prevents Unchecked_Conversion from deinitializing scalar objects -- but to do so requires that range/validity checks be done on the results of some conversions -- hardly "unchecked"). Other places (such as the result of Stream'Read and the results of Sequential_IO.Read for composite types, and especially abort) can't be eliminated in any reasonable way. If you really care about this topic, I suggest you read and reread 13.9.1 until you understand it. (Then join the ARG and explain it to the rest of us. ;-)! This is not at all a simple topic, and the sort of simple rule used by Java does little other than give a false sense of security (and a lot of annoying errors in code that has no problems). Randy.
From: Georg Bauhaus on 3 Dec 2009 06:24 Randy Brukardt schrieb: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message > news:1jcbtmi5rztyp$.norvlhez9i9$.dlg(a)40tude.net... > ... >> No the problem is whether to treat a call to the body as legal. The >> problem >> is that you could not rely on its contract (out Car), in order to be able >> to decide whether this call would "initialize" the object. > [...] > This is not at all a simple topic, and the sort of simple rule used > by Java does little other than give a false sense of security (and a lot of > annoying errors in code that has no problems). After reading your recent hints to compatibility and single pass compilation preventing flow analysis for legality decisions, I noticed the possibility of a restrictions pragma, too. Is it really annoying when programmers are forced to state, explicitly, what they seem to be knowing? That is, for example, "I know that no ELSE is missing in the following code, therefore I have omitted a no-op else branch" X : Some_Type; begin if I_Know_What_This_Does (P) then X := Assign_It; end if; Use_It := Involve (X); When I try to change a program, I find it annoying to *not* see an ELSE branch that does then become a missing ELSE branch. The desired change turns a one-way flow into a blind alley... The code typically looks like this: X : Some_Type; begin if Has_Worked_For_Me (P) then X := Assign_it; end if; I_Can_Use_It := Involve (X); -- (formally fine in Ada, though not in Java or SPARK) The incompleteness of information here can be avoided, to some extent I think, and that's the reason I find the Java rule to be helpful, or the Ada warning, or the pragma which you have suggested. Not really annoying. I can no longer like seeing only half of the cases of Boolean covered in an IF, explicitly. To me, SPARK is not an annoyance when it refuses to accept the above code, since flow analysis reveals the possibility of missing initilization. The Ada programmer may well have decided the halting question for I_Know_What_This_Does or Has_Worked_For_Me. However, I'd sure like to be hinted to his reasons and not just take inspiration from a missing ELSE branch. Could a compiler make some good use of code like the following as a minimal way to express the programmer's valuable knowledge? Or some less intrusive (annoying?) pragma or syntax or ...? X : Some_Type; begin if Whatever (P) then X := Assign_it; else -- Stupid Ada configuration requires this. -- Yeah, X is valid because ... -- ... Whatever (P) is always true, you know. pragma Assert (Some_Type'Valid (X)); null; end if;
From: John B. Matthews on 3 Dec 2009 15:21
In article <hf7i10$enn$1(a)munin.nbi.dk>, "Randy Brukardt" <randy(a)rrsoftware.com> wrote: > "John B. Matthews" <nospam(a)nospam.invalid> wrote in message > news:nospam-9C9974.07353802122009(a)news.aioe.org... > ... > > I'm not especially advocating applying the Java rules to Ada, but I > > like the warning. > > Warnings have no semantic impact in Ada. There are a few places in > the standard that suggest that warnings be generated, but there is no > ideas whatsoever what that might mean. It is purely a quality-of- > implementation issue -- and that is between you and your Ada vendor. Few indeed: ARM 1.1.1, 1.1.5, 13.5.2, 2.8, M.3! This is a virtue in Ada. When reviewing code, my own or others', I'll often use -gnatwa or -Xlint or -Wall or similar. Even if the warning does not represent a genuine oversight, it may suggest the need for a clarifying comment. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> |