* Is this a bug in my code or the compiler? @ 2015-06-12 15:56 David Botton 2015-06-12 16:15 ` Dmitry A. Kazakov ` (3 more replies) 0 siblings, 4 replies; 36+ messages in thread From: David Botton @ 2015-06-12 15:56 UTC (permalink / raw) Given: function Token_Start (Source : in out Awesome.Source.Source_Type'Class) return Character; function Token_End (Source : in out Awesome.Source.Source_Type'Class) return String; The following works: function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class) return String is N : Character := Token_Start (Source); begin return N & Token_End (Source); end Get_Token_Text; The following does not work: function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class) return String is begin return Token_Start (Source) & Token_End (Source); end Get_Token_Text; Token_End is never called and only the value of Token_Start. Thanks David Botton ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 15:56 Is this a bug in my code or the compiler? David Botton @ 2015-06-12 16:15 ` Dmitry A. Kazakov 2015-06-12 17:25 ` G.B. 2015-06-12 17:53 ` David Botton 2015-06-12 16:48 ` Jeffrey R. Carter ` (2 subsequent siblings) 3 siblings, 2 replies; 36+ messages in thread From: Dmitry A. Kazakov @ 2015-06-12 16:15 UTC (permalink / raw) On Fri, 12 Jun 2015 08:56:23 -0700 (PDT), David Botton wrote: > Given: > > function Token_Start (Source : in out Awesome.Source.Source_Type'Class) > return Character; > function Token_End (Source : in out Awesome.Source.Source_Type'Class) > return String; > > The following works: > > function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class) > return String > is > N : Character := Token_Start (Source); > begin > return N & Token_End (Source); > end Get_Token_Text; > > The following does not work: > > function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class) > return String > is > begin > return Token_Start (Source) & Token_End (Source); > end Get_Token_Text; > > Token_End is never called and only the value of Token_Start. That is one of the reasons why in-out's were not allowed for functions in Ada 83. The code is clearly erroneous because the computation order is not defined. Possibly Token_End is called before Token_Start! P.S. When in-out's for functions were discussed I proposed not to allow them as operands in operations that do not state the evaluation order. E.g. function Foo (X : in out T) return Boolean; Foo (A) and Foo (A) -- Illegal Foo (A) and then Foo (A) -- Legal P.P.S. It would become even worse with fine-grained parallelism, as Georg keep on suggesting. If Token_Start (Source) and Token_End (Source) were running in parallel on different cores, that would be great fun! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 16:15 ` Dmitry A. Kazakov @ 2015-06-12 17:25 ` G.B. 2015-06-12 18:00 ` Dmitry A. Kazakov 2015-06-12 17:53 ` David Botton 1 sibling, 1 reply; 36+ messages in thread From: G.B. @ 2015-06-12 17:25 UTC (permalink / raw) On 12.06.15 18:15, Dmitry A. Kazakov wrote: > Foo (A) and Foo (A) -- Illegal > Foo (A) and then Foo (A) -- Legal C has similar features... > P.P.S. It would become even worse with fine-grained parallelism, as Georg > keep on suggesting. Not sure to what this is referring (or how concatenation "&" necessitates the apparent omission of a call, if not a gotcha?). Query-command separation (on objects) seems far better than functions that make their side effects explicit. IIUC, SofCheck has brought tons of aliasing analysis and more to the AdaCore offerings, plus Parasail's automatically parallel loops... So, in Ada 83, when A is of an access type, Foo (A) and Foo (A) -- Legal Moreover, if B and A become pointing to the same object, Foo (A) and Foo (B) -- Legal, same effects Can a compiler detect this? --- So, you'd be asking for pure functions? Or total referential transparency? ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 17:25 ` G.B. @ 2015-06-12 18:00 ` Dmitry A. Kazakov 2015-06-13 10:04 ` Georg Bauhaus 2015-06-13 19:42 ` Brad Moore 0 siblings, 2 replies; 36+ messages in thread From: Dmitry A. Kazakov @ 2015-06-12 18:00 UTC (permalink / raw) On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote: > On 12.06.15 18:15, Dmitry A. Kazakov wrote: >> Foo (A) and Foo (A) -- Illegal >> Foo (A) and then Foo (A) -- Legal > > C has similar features... So? >> P.P.S. It would become even worse with fine-grained parallelism, as Georg >> keep on suggesting. > > Not sure to what this is referring Parallel evaluation of arguments. > Query-command separation (on objects) seems far better than > functions that make their side effects explicit. You forgot about indefinite return values, which are not available for procedures. The real motivation to have functions with side effects is such return values. > So, in Ada 83, when A is of an access type, That does not change anything because: > Foo (A) and Foo (A) -- Legal Only if A is a constant access. Illegal otherwise. With parallelism atomicity of all immutable operations would additionally be required. Which is why that sort of parallelism is a can of worms. > Moreover, if B and A become pointing to the same object, > > Foo (A) and Foo (B) -- Legal, same effects > > Can a compiler detect this? Easily. Access is logically a referential type which, if properly designed, should be a subtype of the target type. Thus the same rules would apply. If access is meant to be a type of its own, like a pointer in C, then the language should better have no such types. > --- So, you'd be asking for pure > functions? Or total referential transparency? Both. Though purity is not enough for parallelism. A pure function may still get broken under parallel access if not atomic. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 18:00 ` Dmitry A. Kazakov @ 2015-06-13 10:04 ` Georg Bauhaus 2015-06-13 10:32 ` Dmitry A. Kazakov 2015-06-13 19:42 ` Brad Moore 1 sibling, 1 reply; 36+ messages in thread From: Georg Bauhaus @ 2015-06-13 10:04 UTC (permalink / raw) On 12.06.15 20:00, Dmitry A. Kazakov wrote: > On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote: > >> On 12.06.15 18:15, Dmitry A. Kazakov wrote: >>> Foo (A) and Foo (A) -- Illegal >>> Foo (A) and then Foo (A) -- Legal >> >> C has similar features... > > So? > >>> P.P.S. It would become even worse with fine-grained parallelism, as Georg >>> keep on suggesting. >> >> Not sure to what this is referring > > Parallel evaluation of arguments. Yes, but where is the difference, exactly, between incorrect due to order dependence, and incorrect due to sharing issues? If nothing is lost by forcing an order on evaluation of arguments on all programs, then I don't know any more why that's not enforced by languages, and why instead we saw Haskell. >> So, in Ada 83, when A is of an access type, > > That does not change anything because: > >> Foo (A) and Foo (A) -- Legal > > Only if A is a constant access. Illegal otherwise. Is there chapter and verse in the 83 LRM for this? I found this in 1.6: "Whenever the reference manual specifies that different parts of a given construct are to be executed in some order that is not defined by the language, this means that the implementation is allowed to execute these parts in any given order, following the rules that result from that given order, but not in parallel. Furthermore, the construct is incorrect if execution of these parts in a different order would have a different effect. Compilers are not required to provide either compilation-time or run-time detection of incorrect order dependences." (No mention of legality here.) So, is GNAT buggy if it accepts this Ada 83 program (you claim that it is *easy* to detect aliasing of A and B): WITH Text_IO; PROCEDURE Par IS TYPE I IS RANGE 1 .. 3; TYPE Ptr IS ACCESS I; A, B: Ptr; V, Legal : Boolean; FUNCTION Foo (X : Ptr) RETURN Boolean IS SEPARATE; PACKAGE Boolean_Io IS NEW Text_IO.Enumeration_IO (Boolean); BEGIN A := NEW I'(1); Boolean_Io.Get (V); IF V THEN B := A; ELSE B := NEW I'(3); END IF; Legal := Foo (A) AND Foo (B); -- legal? END Par; > parallelism is a can of worms. ... if designed without regard to parallel evaluation/execution. That's a matter of course, isn't it? ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-13 10:04 ` Georg Bauhaus @ 2015-06-13 10:32 ` Dmitry A. Kazakov 2015-06-15 10:37 ` G.B. 0 siblings, 1 reply; 36+ messages in thread From: Dmitry A. Kazakov @ 2015-06-13 10:32 UTC (permalink / raw) On Sat, 13 Jun 2015 12:04:57 +0200, Georg Bauhaus wrote: > On 12.06.15 20:00, Dmitry A. Kazakov wrote: >> On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote: >>> Foo (A) and Foo (A) -- Legal >> >> Only if A is a constant access. Illegal otherwise. > > Is there chapter and verse in the 83 LRM for this? Constant access was introduced in Ada 95, I believe. >> parallelism is a can of worms. > > ... if designed without regard to parallel evaluation/execution. > That's a matter of course, isn't it? Well, the parallelism of that kind is too low-level. There could be different approaches to the issue. One is a contract on the arguments evaluation order, which is usually proposed. It does not make much sense because the operation usually has no idea about the semantics of the actual arguments. Another approach would be properties of the operation's results influencing the order, e.g. purity. By-value vs. by-reference mode is an example of this approach. I.e. instead of stating any order, the set of possible orders would be deduced from the expressions of actual arguments. The third approach is explicit ordering syntax, e.g. some extended syntax of the keyed argument association. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-13 10:32 ` Dmitry A. Kazakov @ 2015-06-15 10:37 ` G.B. 2015-06-15 12:27 ` Dmitry A. Kazakov 0 siblings, 1 reply; 36+ messages in thread From: G.B. @ 2015-06-15 10:37 UTC (permalink / raw) On 13.06.15 12:32, Dmitry A. Kazakov wrote: >>> parallelism is a can of worms. >> >> ... if designed without regard to parallel evaluation/execution. >> That's a matter of course, isn't it? > > Well, the parallelism of that kind is too low-level. I find this ascription of low level a little too general, missing opportunities, and pessimistic. After all, processors do manage to provide even lower level parallelism internally, and while difficult to predict, the results seem logically correct. > The third approach is explicit ordering syntax, e.g. some extended syntax > of the keyed argument association. Yes. But how? "&" means "concatenation", therefore sequencing, only at the level of metaphor, not at the level of programming. For operators, consider function "+" (Left : S; Right : T) return R; where + is any infix operator. Knowing that the order of evaluation of Left and Right is not specified leads to better design: If you know it isn't, then you start fixing the interface of S and T in view of "+". To me, this looks like "normal", good O-O design principles at work, in that Left's operation does not rely on Right's internal state, and vice versa. It avoids spaghetti style design, as a consequence of no order of evaluation being specified. Conversely, if order is needed when evaluating input to "+", i.e. if a particular succession of states is needed, then this order can be established using a constant, or a renaming. So in sum, suppose the absence of an ordering stricture could be made explicit syntactically. Would it be a boon, both driving better interfaces and also an aid to understanding? ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-15 10:37 ` G.B. @ 2015-06-15 12:27 ` Dmitry A. Kazakov 2015-06-15 12:31 ` Simon Wright 0 siblings, 1 reply; 36+ messages in thread From: Dmitry A. Kazakov @ 2015-06-15 12:27 UTC (permalink / raw) On Mon, 15 Jun 2015 12:37:37 +0200, G.B. wrote: > On 13.06.15 12:32, Dmitry A. Kazakov wrote: > >>>> parallelism is a can of worms. >>> >>> ... if designed without regard to parallel evaluation/execution. >>> That's a matter of course, isn't it? >> >> Well, the parallelism of that kind is too low-level. > > I find this ascription of low level a little too general, > missing opportunities, and pessimistic. After all, processors > do manage to provide even lower level parallelism internally, > and while difficult to predict, the results seem logically > correct. Determinism /= high level. >> The third approach is explicit ordering syntax, e.g. some extended syntax >> of the keyed argument association. > > Yes. But how? > > "&" means "concatenation", therefore sequencing, only at the level of > metaphor, not at the level of programming. For operators, consider > > function "+" (Left : S; Right : T) return R; E.g. "+" (Right #> Y, Left #> X); #> reads evaluated left-to-right. > To me, this looks like "normal", good O-O design principles at work, > in that Left's operation does not rely on Right's internal state, and > vice versa. It is not about the state in this case. When the body of + is called its arguments already reached their states. The concept of evaluation order is orthogonal to procedural/states POV. Compare procedure with entry point. Entry point is nothing but a procedure with an evaluation order enforced on separate tasks. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-15 12:27 ` Dmitry A. Kazakov @ 2015-06-15 12:31 ` Simon Wright 2015-06-15 13:16 ` Dmitry A. Kazakov 0 siblings, 1 reply; 36+ messages in thread From: Simon Wright @ 2015-06-15 12:31 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > "+" (Right #> Y, Left #> X); > > #> reads evaluated left-to-right. "+" (Right => Y and then Left => X); maybe. And you could even put it on the spec. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-15 12:31 ` Simon Wright @ 2015-06-15 13:16 ` Dmitry A. Kazakov 2015-06-15 14:56 ` Simon Wright 0 siblings, 1 reply; 36+ messages in thread From: Dmitry A. Kazakov @ 2015-06-15 13:16 UTC (permalink / raw) On Mon, 15 Jun 2015 13:31:33 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> "+" (Right #> Y, Left #> X); >> >> #> reads evaluated left-to-right. > > "+" (Right => Y and then Left => X); > > maybe. "and then" could be ambiguous. > And you could even put it on the spec. You mean: function "+" (Left : T and then Right : T) return T; ? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-15 13:16 ` Dmitry A. Kazakov @ 2015-06-15 14:56 ` Simon Wright 2015-06-15 15:03 ` G.B. 0 siblings, 1 reply; 36+ messages in thread From: Simon Wright @ 2015-06-15 14:56 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Mon, 15 Jun 2015 13:31:33 +0100, Simon Wright wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> >>> "+" (Right #> Y, Left #> X); >>> >>> #> reads evaluated left-to-right. >> >> "+" (Right => Y and then Left => X); >> >> maybe. > > "and then" could be ambiguous. ? >> And you could even put it on the spec. > > You mean: > > function "+" (Left : T and then Right : T) return T; > > ? Yes, I guess, but it's not going to happen! ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-15 14:56 ` Simon Wright @ 2015-06-15 15:03 ` G.B. 0 siblings, 0 replies; 36+ messages in thread From: G.B. @ 2015-06-15 15:03 UTC (permalink / raw) On 15.06.15 16:56, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Mon, 15 Jun 2015 13:31:33 +0100, Simon Wright wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>>> "+" (Right #> Y, Left #> X); >>>> >>>> #> reads evaluated left-to-right. >>> >>> "+" (Right => Y and then Left => X); >>> >>> maybe. >> >> "and then" could be ambiguous. > > ? It could be a little dangerous in general if there is a default parameter, (Right => Y and then Left >= X); Also, if there were permission to drop parentheses around a record literal in (Right => Y and then (Left => X)); if this were to make sense somehow. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 18:00 ` Dmitry A. Kazakov 2015-06-13 10:04 ` Georg Bauhaus @ 2015-06-13 19:42 ` Brad Moore 1 sibling, 0 replies; 36+ messages in thread From: Brad Moore @ 2015-06-13 19:42 UTC (permalink / raw) On 2015-06-12 12:00 PM, Dmitry A. Kazakov wrote: > On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote: > >> On 12.06.15 18:15, Dmitry A. Kazakov wrote: >>> Foo (A) and Foo (A) -- Illegal >>> Foo (A) and then Foo (A) -- Legal >> >> C has similar features... > > So? > >>> P.P.S. It would become even worse with fine-grained parallelism, as Georg >>> keep on suggesting. >> >> Not sure to what this is referring > > Parallel evaluation of arguments. In the above case with regard to implicit parallelism, the compiler should be able to determine that the two calls both involve modifications the same storage, which would be a data race, and then rule out parallelism and thus generate sequential code. So the issue here is not about parallelism, but about ordering of evaluation for the sequential case. For the sequential case, I would think that a good compiler could also detect that an expression with multiple calls with in out parameters to the same storage is likely a problem with evaluation order, and generate a warning to the programmer, which could be averted by coding with "and then" for force evaluation order. If your compiler does not generate such a warning, it might be good to ask your vendor to provide such a warning. Or a programmer could adopt a programming style to use "and then" for the general case, which I believe could be checked by a tool such as AdaControl. This should work for the case Boolean sub expressions, but doesn't help in the case of concatenation operations. Hopefully, the compiler could at least generate warnings for this case, then the programmer can decide how best to address the warning. > >> Query-command separation (on objects) seems far better than >> functions that make their side effects explicit. > > You forgot about indefinite return values, which are not available for > procedures. The real motivation to have functions with side effects is such > return values. > >> So, in Ada 83, when A is of an access type, > > That does not change anything because: > >> Foo (A) and Foo (A) -- Legal > > Only if A is a constant access. Illegal otherwise. > > With parallelism atomicity of all immutable operations would additionally > be required. Which is why that sort of parallelism is a can of worms. > >> Moreover, if B and A become pointing to the same object, >> >> Foo (A) and Foo (B) -- Legal, same effects >> >> Can a compiler detect this? In Ada 2012, we have the attributes 'Has_Same_Storage and 'Overlaps_Storage. These were introduced to facilitate writing preconditions for a subprogram. One would think that if these are available for checking multiple parameters of a subprogram, the compiler could also do similar checks for the parameters of subprograms that are part of the same expression. In some cases, this could be a compile time check, but in others, it may need to be a run-time check, that possibly could be enabled/disabled via compiler options. Brad > > Easily. Access is logically a referential type which, if properly designed, > should be a subtype of the target type. Thus the same rules would apply. If > access is meant to be a type of its own, like a pointer in C, then the > language should better have no such types. > >> --- So, you'd be asking for pure >> functions? Or total referential transparency? > > Both. > > Though purity is not enough for parallelism. A pure function may still get > broken under parallel access if not atomic. > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 16:15 ` Dmitry A. Kazakov 2015-06-12 17:25 ` G.B. @ 2015-06-12 17:53 ` David Botton 2015-06-12 18:11 ` Dmitry A. Kazakov ` (4 more replies) 1 sibling, 5 replies; 36+ messages in thread From: David Botton @ 2015-06-12 17:53 UTC (permalink / raw) > That is one of the reasons why in-out's were not allowed for functions in > Ada 83. The code is clearly erroneous because the computation order is not > defined. Possibly Token_End is called before Token_Start! A programmer having to worry about order of operation in a concatenation operation is a language flaw in my opinion. I can accept the issue in evaluation order of Boolean expressions or numerics (and knew of that), but not in non numeric types. David Botton ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 17:53 ` David Botton @ 2015-06-12 18:11 ` Dmitry A. Kazakov 2015-06-12 18:43 ` marciant 2015-06-12 19:37 ` Jeffrey R. Carter ` (3 subsequent siblings) 4 siblings, 1 reply; 36+ messages in thread From: Dmitry A. Kazakov @ 2015-06-12 18:11 UTC (permalink / raw) On Fri, 12 Jun 2015 10:53:04 -0700 (PDT), David Botton wrote: >> That is one of the reasons why in-out's were not allowed for functions in >> Ada 83. The code is clearly erroneous because the computation order is not >> defined. Possibly Token_End is called before Token_Start! > > A programmer having to worry about order of operation in a concatenation > operation is a language flaw in my opinion. Yes, but in Ada 83 side effects in functions were frowned at. The troubles arose first with side effects used quite liberally in the standard library and by most programmers. > I can accept the issue in > evaluation order of Boolean expressions or numerics (and knew of that), > but not in non numeric types. The name suggests that short-cut logical operations were considered as a syntax sugar to save keystrokes - a replacement for nested IFs. Quickly enough it was discovered that in some contexts you cannot have IFs (e.g. in barriers) and that people disliked nested IFs anyway. But the issues of ordering and re-ordering, eager vs. lazy evaluation, aliasing, purity, atomicity are not limited to Boolean types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 18:11 ` Dmitry A. Kazakov @ 2015-06-12 18:43 ` marciant 0 siblings, 0 replies; 36+ messages in thread From: marciant @ 2015-06-12 18:43 UTC (permalink / raw) On Friday, June 12, 2015 at 2:11:33 PM UTC-4, Dmitry A. Kazakov wrote: > > The name suggests that short-cut logical operations were considered as a > syntax sugar to save keystrokes - a replacement for nested IFs. Quickly > enough it was discovered that in some contexts you cannot have IFs (e.g. in > barriers) and that people disliked nested IFs anyway. > (nit-picker alert! ;-) They are called short-circuit not short-cut, short in that normally all parts of a boolean expression are evaluated (even those that would cause an exception with elements some values). That was to improve testability: you are normally sure that some part of an expression isn't actually never evaluated with some given test input. It also can minimize execution time variance. I think that the canonical example is something like "if x/=0 and then y/x=n then ..." but I see what you mean by less nested if's. But avoiding the nested if's was less about minimizing typing and more about increasing readability. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 17:53 ` David Botton 2015-06-12 18:11 ` Dmitry A. Kazakov @ 2015-06-12 19:37 ` Jeffrey R. Carter 2015-06-12 19:55 ` Simon Wright 2015-06-12 19:39 ` jan.de.kruyf ` (2 subsequent siblings) 4 siblings, 1 reply; 36+ messages in thread From: Jeffrey R. Carter @ 2015-06-12 19:37 UTC (permalink / raw) On 06/12/2015 10:53 AM, David Botton wrote: > > A programmer having to worry about order of operation in a concatenation > operation is a language flaw in my opinion. I can accept the issue in > evaluation order of Boolean expressions or numerics (and knew of that), but > not in non numeric types. Boolean is a non-numeric type. You must mean "non-numeric types other than boolean types". You're using function "&" (Left : in Character; Right : in String) return String; which is predefined (and a similar "&" is predefined for all 1-D array types), and want it to have different evaluation rules than if you define function "&" (Left : in Integer; Right : in Integer) return Integer; ? Order of evaluation is not defined for any subprogram (with more than 1 parameter). That's a simple rule. What you want seems much more complex. -- Jeff Carter "Unix and C are the ultimate computer viruses." Richard Gabriel 99 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 19:37 ` Jeffrey R. Carter @ 2015-06-12 19:55 ` Simon Wright 2015-06-12 20:40 ` Jeffrey R. Carter 0 siblings, 1 reply; 36+ messages in thread From: Simon Wright @ 2015-06-12 19:55 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: > function "&" (Left : in Character; Right : in String) return String; function "&" (Left : in Character; Right : in Character) return String; ARM 4.5.3(4) (which actually defaults the mode rather than saying 'in') ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 19:55 ` Simon Wright @ 2015-06-12 20:40 ` Jeffrey R. Carter 2015-06-12 21:40 ` Simon Wright 0 siblings, 1 reply; 36+ messages in thread From: Jeffrey R. Carter @ 2015-06-12 20:40 UTC (permalink / raw) On 06/12/2015 12:55 PM, Simon Wright wrote: > "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: > >> function "&" (Left : in Character; Right : in String) return String; > > function "&" (Left : in Character; Right : in Character) return String; > > ARM 4.5.3(4) (which actually defaults the mode rather than saying 'in') No, the function he was using as his right argument returned String. -- Jeff Carter "Unix and C are the ultimate computer viruses." Richard Gabriel 99 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 20:40 ` Jeffrey R. Carter @ 2015-06-12 21:40 ` Simon Wright 0 siblings, 0 replies; 36+ messages in thread From: Simon Wright @ 2015-06-12 21:40 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: > On 06/12/2015 12:55 PM, Simon Wright wrote: >> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: >> >>> function "&" (Left : in Character; Right : in String) return String; >> >> function "&" (Left : in Character; Right : in Character) return String; >> >> ARM 4.5.3(4) (which actually defaults the mode rather than saying 'in') > > No, the function he was using as his right argument returned String. I'll get me coat ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 17:53 ` David Botton 2015-06-12 18:11 ` Dmitry A. Kazakov 2015-06-12 19:37 ` Jeffrey R. Carter @ 2015-06-12 19:39 ` jan.de.kruyf 2015-06-12 22:10 ` David Botton 2015-06-14 3:13 ` Randy Brukardt 2015-06-14 3:21 ` Randy Brukardt 4 siblings, 1 reply; 36+ messages in thread From: jan.de.kruyf @ 2015-06-12 19:39 UTC (permalink / raw) On Friday, June 12, 2015 at 7:53:07 PM UTC+2, David Botton wrote: > > A programmer having to worry about order of operation in a concatenation operation is a language flaw in my opinion. I can accept the issue in evaluation order of Boolean expressions or numerics (and knew of that), but not in non numeric types. Or, uh . . . A language designer having to worry about... :) I was going to post when I first saw the issue. But maybe I must still say it: Programming twice removed from the bare metal might _seem_ easy and convenient, but it _is_ not in my experience. Plenty of 'wait-a-bit' thorns await those who think otherwise. A computer is a tool. A language is a tool. When you know your tools you can make wonders. When you dont . . you might need a few lessons of that most detested computer scientist Prof Wirth. :) cheers, keep well David, j. > > David Botton ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 19:39 ` jan.de.kruyf @ 2015-06-12 22:10 ` David Botton 2015-06-13 0:19 ` Dennis Lee Bieber 2015-06-13 14:21 ` jan.de.kruyf 0 siblings, 2 replies; 36+ messages in thread From: David Botton @ 2015-06-12 22:10 UTC (permalink / raw) > Or, uh . . . A language designer having to worry about... :) Actually it is exactly what a designer should think about. Want to prevent when and how reasonable errors by the use of that language. > I was going to post when I first saw the issue. But maybe I must still say it: > Programming twice removed from the bare metal might _seem_ easy and convenient, but it _is_ not in my experience. Plenty of 'wait-a-bit' thorns await those who think otherwise. Yes, I could just write in assembly, but that would remove the efficiency of my creativity as a programmer :) I choose my tools to assist me in both beautiful expression of the idea that others can read (and as Wirth points out in Programming in Oberon, Assembly is unreadable) and to assist me in correctness. > A computer is a tool. A language is a tool. When you know your tools you can make wonders. When you dont . . you might need a few lessons of that most detested computer scientist Prof Wirth. :) Not sure I got that one. I assume first I was wrong and the tool had a different idea than I, as was evident. Not sure though how Wirth fits in, since in the next line in the Wirth text I just mentioned, he points out a program that is not readable by humans is worthless. (I wish he would have qualified his statements a bit more and sorry for not exact quotes but close enough paraphrase here. I don't have time to grab the PDF). I would say that concatenation operations with order of evaluation not significant is an unexpected gotcha for most human readers and so a language should not tolerate it. David Botton ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 22:10 ` David Botton @ 2015-06-13 0:19 ` Dennis Lee Bieber 2015-06-13 14:21 ` jan.de.kruyf 1 sibling, 0 replies; 36+ messages in thread From: Dennis Lee Bieber @ 2015-06-13 0:19 UTC (permalink / raw) On Fri, 12 Jun 2015 15:10:21 -0700 (PDT), David Botton <david@botton.com> declaimed the following: >Yes, I could just write in assembly, but that would remove the efficiency of my creativity as a programmer :) I choose my tools to assist me in both beautiful expression of the idea that others can read (and as Wirth points out in Programming in Oberon, Assembly is unreadable) and to assist me in correctness. > Assembly is tedious -- and hardware specific (how much time did the PowerPC designers spend coming up with "EIEIO" as an instruction? rather than something like memsync; 68K with its differentiation between data and address registers, along with lots of addressing modes; ARM Thumb-2 [purported RISC architecture] with some instructions essentially embedding what would be stand-alone shift instructions as just parts of the addressing mode... Give me a good old "logical" Sigma-6 meta-symbol file!) PERL is unreadable... -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 22:10 ` David Botton 2015-06-13 0:19 ` Dennis Lee Bieber @ 2015-06-13 14:21 ` jan.de.kruyf 1 sibling, 0 replies; 36+ messages in thread From: jan.de.kruyf @ 2015-06-13 14:21 UTC (permalink / raw) On Saturday, June 13, 2015 at 12:10:22 AM UTC+2, David Botton wrote: > > Or, uh . . . A language designer having to worry about... :) > David, > Actually it is exactly what a designer should think about. Want to prevent when and how reasonable errors by the use of that language. > Of course I agree with you there; but there is a fine line, that we as programmers are not always aware of. Which is the balance between nannying the programmers and giving them true power. (not in the C sense) > > Yes, I could just write in assembly, but that would remove the efficiency of my creativity as a programmer :) I choose my tools to assist me in both beautiful expression of the idea that others can read (and as Wirth points out in Programming in Oberon, Assembly is unreadable) and to assist me in correctness. Which is fully my sentiment. But I grew up with those 8 bitters. So historically I might be more inclined not to trust my tools, unless I fully understand them. Which is very hard of course these days. > > Not sure I got that one. I assume first I was wrong and the tool had a different idea than I, as was evident. I always blame the tool first (shame faced . .) but that got me quite far because then I start taking the tools apart, to see what is cooking. (and most of the time find it is me) > Not sure though how Wirth fits in I was just repeating the sentiment of the group in a joking way, as I understood it a while back. > (I wish he would have qualified his statements a bit more. He killed his life's work by not communicating. And what is worse, the faculty had no real way forward when he left. Nothing is happening there anymore. His secrets are revealed in his code. > I would say that concatenation operations with order of evaluation not significant is an unexpected gotcha for most human readers and so a language should not tolerate it. Or perhaps this "must have" runs amok with the limitations Dmitry pointed out in the second post of this thread, but the designers did not realize at the time (it was still single processors then). This touches the deepest levels of computer science. Many thick books have been written about order of evaluation and concurrent execution. Look at the amount of work it took to clean up the linux kernel so it could be more or less real time and pre-emptible. Now it will take a lot of courage to go back a few steps and see if we can implement this thing in a different way, which automatically resolves the concurrency issue. If you are interested in that kind of thing, have a look at the chapter about texts in Project Oberon (the book that describes the operating system, and the compiler) He found a very clever way to deal with strings, texts, streams fonts etc. Any text consists of a collection of pieces (strings) in a double linked list. And each piece has attributes (font, color, anything). And a text knows how to load itself and store itself (That is also where the mess gets sorted and the pieces are collected into bigger pieces, where the attributes allow) So if you want to insert some text you just split the piece in two and insert a new piece, and so on. The concept looks very messy at first, but it works very fast and it automatically deals with wide strings etc. by virtue of the attributes. As a programmer you have a unified and coherent view of the whole text business, except for the most trivial strings, there you just roll your own if needed. enjoy your weekend, j. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 17:53 ` David Botton ` (2 preceding siblings ...) 2015-06-12 19:39 ` jan.de.kruyf @ 2015-06-14 3:13 ` Randy Brukardt 2015-06-14 3:21 ` Randy Brukardt 4 siblings, 0 replies; 36+ messages in thread From: Randy Brukardt @ 2015-06-14 3:13 UTC (permalink / raw) >David Botton" <david@botton.com> wrote in message >news:afb6fe82-1f67-49a8-b4b1-f814a71ba8fd@googlegroups.com... >> That is one of the reasons why in-out's were not allowed for functions in >> Ada 83. The code is clearly erroneous because the computation order is >> not >> defined. Possibly Token_End is called before Token_Start! > > A programmer having to worry about order of operation in a concatenation > operation is a language flaw in my opinion. I can accept the issue in > evaluation > order of Boolean expressions or numerics (and knew of that), but not in > non numeric types. Yes, but at least we tried to prevent obvious cases. (It's way too late to change the order of evaluation rules for Ada!) And you need a lot more complex program to show a problem. Simple cases are illegal; we only made the rules apply to simple cases so that there clearly was a problem before the code was rejected. Randy. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 17:53 ` David Botton ` (3 preceding siblings ...) 2015-06-14 3:13 ` Randy Brukardt @ 2015-06-14 3:21 ` Randy Brukardt 4 siblings, 0 replies; 36+ messages in thread From: Randy Brukardt @ 2015-06-14 3:21 UTC (permalink / raw) "David Botton" <david@botton.com> wrote in message news:afb6fe82-1f67-49a8-b4b1-f814a71ba8fd@googlegroups.com... >> That is one of the reasons why in-out's were not allowed for functions in >> Ada 83. The code is clearly erroneous because the computation order is >> not >> defined. Possibly Token_End is called before Token_Start! > > A programmer having to worry about order of operation in a concatenation > operation is a language flaw in my opinion. I can accept the issue in > evaluation order of Boolean expressions or numerics (and knew of that), > but not in non numeric types. Lots of people would agree with you, but neither J. Ichbiah or STT would, so Ada doesn't define the order of evaluation of almost anything: parameters (not just concat, but in all subprogram calls), aggregate components, and many more things. It would be way too disruptive to try to introduce any such rules now, especially as there are legal dispatching calls that cannot be evaluated left-to-right. The rules in 6.4.1 are supposed to prevent the worst problems, but of course they only work if correctly implemented. I'd suggest submitting one or more ACATS tests. :-) Randy. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 15:56 Is this a bug in my code or the compiler? David Botton 2015-06-12 16:15 ` Dmitry A. Kazakov @ 2015-06-12 16:48 ` Jeffrey R. Carter 2015-06-13 13:33 ` Jacob Sparre Andersen 2015-06-14 3:10 ` Randy Brukardt 3 siblings, 0 replies; 36+ messages in thread From: Jeffrey R. Carter @ 2015-06-12 16:48 UTC (permalink / raw) On 06/12/2015 08:56 AM, David Botton wrote: > Given: > > function Token_Start (Source : in out Awesome.Source.Source_Type'Class) > return Character; > function Token_End (Source : in out Awesome.Source.Source_Type'Class) > return String; > > The following works: > > function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class) > return String > is > N : Character := Token_Start (Source); > begin > return N & Token_End (Source); > end Get_Token_Text; > > The following does not work: > > function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class) > return String > is > begin > return Token_Start (Source) & Token_End (Source); > end Get_Token_Text; Given that the Source parameters to both Token_Start and Token_End are mode "in out", I presume that both functions modify Source and therefore, Token_Start must be called before Token_End. Your 1st version ensures this order; your 2nd does not. You are presuming an order of evaluation of the parameters to "&" that is not guaranteed. What happens if Token_End is called 1st? -- Jeff Carter "Unix and C are the ultimate computer viruses." Richard Gabriel 99 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 15:56 Is this a bug in my code or the compiler? David Botton 2015-06-12 16:15 ` Dmitry A. Kazakov 2015-06-12 16:48 ` Jeffrey R. Carter @ 2015-06-13 13:33 ` Jacob Sparre Andersen 2015-06-13 15:15 ` J-P. Rosen 2015-06-14 3:18 ` Randy Brukardt 2015-06-14 3:10 ` Randy Brukardt 3 siblings, 2 replies; 36+ messages in thread From: Jacob Sparre Andersen @ 2015-06-13 13:33 UTC (permalink / raw) David Botton wrote: > function Token_Start (Source : in out Awesome.Source.Source_Type'Class) > return Character; > function Token_End (Source : in out Awesome.Source.Source_Type'Class) > return String; > return Token_Start (Source) & Token_End (Source); Doesn't your compiler warn you about modifying Source in two places (roughly) at the same time? GNAT 4.9 complains loudly about the roughly similar case: procedure P (A, B : in out T); P (C, C); But I can't get it to complain about a simplified variation of your case. Maybe there is an AdaControl rule to detect this kind of problem. But it is an obviously faulty expression, so it would make most sense if it was forbidden in the language. Greetings, Jacob -- "It is very easy to get ridiculously confused about the tenses of time travel, but most things can be resolved by a sufficiently large ego." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-13 13:33 ` Jacob Sparre Andersen @ 2015-06-13 15:15 ` J-P. Rosen 2015-06-13 16:43 ` Jacob Sparre Andersen 2015-06-14 3:18 ` Randy Brukardt 1 sibling, 1 reply; 36+ messages in thread From: J-P. Rosen @ 2015-06-13 15:15 UTC (permalink / raw) Le 13/06/2015 15:33, Jacob Sparre Andersen a écrit : > procedure P (A, B : in out T); > > P (C, C); > > But I can't get it to complain about a simplified variation of your > case. > > Maybe there is an AdaControl rule to detect this kind of problem. Of course. It's called Parameter_Aliasing :-) -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-13 15:15 ` J-P. Rosen @ 2015-06-13 16:43 ` Jacob Sparre Andersen 2015-06-13 20:50 ` J-P. Rosen 0 siblings, 1 reply; 36+ messages in thread From: Jacob Sparre Andersen @ 2015-06-13 16:43 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: > Le 13/06/2015 15:33, Jacob Sparre Andersen a écrit : >> procedure P (A, B : in out T); >> >> P (C, C); >> >> But I can't get it to complain about a simplified variation of your >> case. >> >> Maybe there is an AdaControl rule to detect this kind of problem. > Of course. It's called Parameter_Aliasing :-) I tried it without luck on this test case: % cat bad_style_2.adb with Ada.Integer_Text_IO, Ada.Text_IO; procedure Bad_Style_2 is function F (I : in out Integer) return Character; function G (I : in out Integer) return String; function F (I : in out Integer) return Character is begin return R : Character do if I < 0 then R := '-'; else R := '+'; end if; I := 2 * I; end return; end F; function G (I : in out Integer) return String is begin return R : constant String := Integer'Image (I) do I := I - 1; end return; end G; C : Integer := 3; begin Ada.Text_IO.Put_Line (F (C) & G (C)); Ada.Integer_Text_IO.Put (C); end Bad_Style_2; % adactl -l 'check parameter_aliasing' bad_style_2.adb % I.e. no detection of "expression parameter aliasing" (or what we should call it). I think it is only slightly harder to detect than plain parameter aliasing, but I'm not yet quite proficient enough in ASIS to promise to contribute a new rule to AdaControl. Greetings, Jacob -- "It is very easy to get ridiculously confused about the tenses of time travel, but most things can be resolved by a sufficiently large ego." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-13 16:43 ` Jacob Sparre Andersen @ 2015-06-13 20:50 ` J-P. Rosen 0 siblings, 0 replies; 36+ messages in thread From: J-P. Rosen @ 2015-06-13 20:50 UTC (permalink / raw) Le 13/06/2015 18:43, Jacob Sparre Andersen a écrit : >>> Maybe there is an AdaControl rule to detect this kind of problem. >> > Of course. It's called Parameter_Aliasing :-) > I tried it without luck on this test case: [Snip example on a function call] Yeap, it works on procedure and entry calls, I didn't put (yet) the case of function calls... Added to my todo list for the next version. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-13 13:33 ` Jacob Sparre Andersen 2015-06-13 15:15 ` J-P. Rosen @ 2015-06-14 3:18 ` Randy Brukardt 1 sibling, 0 replies; 36+ messages in thread From: Randy Brukardt @ 2015-06-14 3:18 UTC (permalink / raw) "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message news:87si9vohrg.fsf@adaheads.sparre-andersen.dk... > David Botton wrote: > >> function Token_Start (Source : in out >> Awesome.Source.Source_Type'Class) >> return Character; >> function Token_End (Source : in out Awesome.Source.Source_Type'Class) >> return String; > >> return Token_Start (Source) & Token_End (Source); > > Doesn't your compiler warn you about modifying Source in two places > (roughly) at the same time? As I noted, this code is illegal in Ada. Forget the warning, and fix the compiler to detect the error! Randy. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-12 15:56 Is this a bug in my code or the compiler? David Botton ` (2 preceding siblings ...) 2015-06-13 13:33 ` Jacob Sparre Andersen @ 2015-06-14 3:10 ` Randy Brukardt 2015-06-14 9:02 ` Jacob Sparre Andersen 3 siblings, 1 reply; 36+ messages in thread From: Randy Brukardt @ 2015-06-14 3:10 UTC (permalink / raw) "David Botton" <david@botton.com> wrote in message news:4f4cd4b1-0a6d-441b-a4f7-98add70e4e1e@googlegroups.com... > Given: > > function Token_Start (Source : in out Awesome.Source.Source_Type'Class) > return Character; > function Token_End (Source : in out Awesome.Source.Source_Type'Class) > return String; > > The following works: > > function Get_Token_Text (Source : in out > Awesome.Source.Source_Type'Class) > return String > is > N : Character := Token_Start (Source); > begin > return N & Token_End (Source); > end Get_Token_Text; > > The following does not work: > > function Get_Token_Text (Source : in out > Awesome.Source.Source_Type'Class) > return String > is > begin > return Token_Start (Source) & Token_End (Source); > end Get_Token_Text; > > Token_End is never called and only the value of Token_Start. I would have expected this second expression to be illegal, because it seems to violate 6.4.1(6.18-19/3). That rule was introduced in Ada 2012 along with "in out" function parameters to avoid "obvious" dependence on order of evaluation. The rule is: If a construct C has two or more direct constituents that are names or expressions whose evaluation may occur in an arbitrary order, at least one of which contains a function call with an in out or out parameter, then the construct is legal only if: For each name N that is passed as a parameter of mode in out or out to some inner function call C2 (not including the construct C itself), there is no other name anywhere within a direct constituent of the construct C other than the one containing C2, that is known to refer to the same object. (Here C is "&", N is Source, and C2 is Token_Start; the rule says that Source can't appear outside of the call of Token_Start, and it does. I'd suggest filing a bug report.) Randy. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-14 3:10 ` Randy Brukardt @ 2015-06-14 9:02 ` Jacob Sparre Andersen 2015-06-14 12:48 ` brbarkstrom 2015-06-15 22:06 ` Randy Brukardt 0 siblings, 2 replies; 36+ messages in thread From: Jacob Sparre Andersen @ 2015-06-14 9:02 UTC (permalink / raw) Randy Brukardt wrote: > I would have expected this second expression to be illegal, because it > seems to violate 6.4.1(6.18-19/3). That rule was introduced in Ada > 2012 along with "in out" function parameters to avoid "obvious" > dependence on order of evaluation. Is there an ACATS test for that rule? (If not, then I'll volunteer to formulate and submit one.) Greetings, Jacob -- "It is very easy to get ridiculously confused about the tenses of time travel, but most things can be resolved by a sufficiently large ego." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-14 9:02 ` Jacob Sparre Andersen @ 2015-06-14 12:48 ` brbarkstrom 2015-06-15 22:06 ` Randy Brukardt 1 sibling, 0 replies; 36+ messages in thread From: brbarkstrom @ 2015-06-14 12:48 UTC (permalink / raw) Oddly, the June 2015 issue of the Comm. ACM showed up on the same day I noted this thread. That issue contains Leslie Lamport's 2013 Turing Prize lecture Lamport, L., 2015: The Computer Science of Concurrency: The Early Years, CACM, Vol. 58, No. 6, pp. 71-76. The paper is reasonably readable if you don't mind a bit of math. It seems to me that David's program has instances that fall into problems that require mutual exclusion, which Lamport discusses in a fair amount of detail. As he comments concurrency problems are subtle and complex - and hard to solve correctly. I'm not sure whether it's fair to expect the compiler to be able to deal by itself with a problem that might involve an underspecified set of preconditions. Lamport might suggest that it needs a mathematical specification of the type he sets up in his TLA+ language (see <http://research.microsoft.com/en-us/um/people/lamport/tla/tla.html>). In the Ada world, this might be one of the targets of SPARK. Bruce B. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Is this a bug in my code or the compiler? 2015-06-14 9:02 ` Jacob Sparre Andersen 2015-06-14 12:48 ` brbarkstrom @ 2015-06-15 22:06 ` Randy Brukardt 1 sibling, 0 replies; 36+ messages in thread From: Randy Brukardt @ 2015-06-15 22:06 UTC (permalink / raw) "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message news:87k2v6oe6q.fsf@adaheads.sparre-andersen.dk... > Randy Brukardt wrote: > >> I would have expected this second expression to be illegal, because it >> seems to violate 6.4.1(6.18-19/3). That rule was introduced in Ada >> 2012 along with "in out" function parameters to avoid "obvious" >> dependence on order of evaluation. > > Is there an ACATS test for that rule? (If not, then I'll volunteer to > formulate and submit one.) Not yet. When I was going to write one, there was some talk of changing the rules, so I put it off. And of course it never made it back to the top (yet). Randy. ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2015-06-15 22:06 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-12 15:56 Is this a bug in my code or the compiler? David Botton 2015-06-12 16:15 ` Dmitry A. Kazakov 2015-06-12 17:25 ` G.B. 2015-06-12 18:00 ` Dmitry A. Kazakov 2015-06-13 10:04 ` Georg Bauhaus 2015-06-13 10:32 ` Dmitry A. Kazakov 2015-06-15 10:37 ` G.B. 2015-06-15 12:27 ` Dmitry A. Kazakov 2015-06-15 12:31 ` Simon Wright 2015-06-15 13:16 ` Dmitry A. Kazakov 2015-06-15 14:56 ` Simon Wright 2015-06-15 15:03 ` G.B. 2015-06-13 19:42 ` Brad Moore 2015-06-12 17:53 ` David Botton 2015-06-12 18:11 ` Dmitry A. Kazakov 2015-06-12 18:43 ` marciant 2015-06-12 19:37 ` Jeffrey R. Carter 2015-06-12 19:55 ` Simon Wright 2015-06-12 20:40 ` Jeffrey R. Carter 2015-06-12 21:40 ` Simon Wright 2015-06-12 19:39 ` jan.de.kruyf 2015-06-12 22:10 ` David Botton 2015-06-13 0:19 ` Dennis Lee Bieber 2015-06-13 14:21 ` jan.de.kruyf 2015-06-14 3:13 ` Randy Brukardt 2015-06-14 3:21 ` Randy Brukardt 2015-06-12 16:48 ` Jeffrey R. Carter 2015-06-13 13:33 ` Jacob Sparre Andersen 2015-06-13 15:15 ` J-P. Rosen 2015-06-13 16:43 ` Jacob Sparre Andersen 2015-06-13 20:50 ` J-P. Rosen 2015-06-14 3:18 ` Randy Brukardt 2015-06-14 3:10 ` Randy Brukardt 2015-06-14 9:02 ` Jacob Sparre Andersen 2015-06-14 12:48 ` brbarkstrom 2015-06-15 22:06 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox