Gnat GPL 2010 available soon (conditional expressions)
in [ADA]
|
Prev: Ann: Generic Image Decoder v.01
Next: ANN: Tables 1.10
From: Dmitry A. Kazakov on 28 Jun 2010 13:37 On Mon, 28 Jun 2010 19:04:03 +0200, Georg Bauhaus wrote: > On 28.06.10 18:36, Dmitry A. Kazakov wrote: >> On Mon, 28 Jun 2010 16:47:50 +0200, Georg Bauhaus wrote: >> >>> On 29.06.10 16:08, Dmitry A. Kazakov wrote: >>> >>>>> The use of conditional expressions in "normal" code is optional (I >>>>> think) but I can see that once you add them to the language, forbidding >>>>> them from normal code would seem oddly inconsistent. >>>> >>>> Yes. This is exactly same as anonymous access types and other "workaround" >>>> things. Once you let them in, they won't leave. >>> >>> Conditional expressions will not be everywhere if your project uses >>> a source code analysis tool with suitable settings. >> >> The only code analysis tool is the compiler, otherwise the language is to >> be fixed. > > Or let industry decide which Ada language profiles they would like > standardized. I don't think that industry is capable of making wise decisions. So far they have chosen MISRA C. > A language profile such as the subset of Ada defined by SPARK, > with recursion and named pointers added. Maybe including generics > with formal types only. I don't like the idea of breaking language into many clades. Especially Ada, of which user base is pretty thin. In my view instead of specifying undesired constructs (the profile), the programmer should do what he wants to be proved. The compiler should try and then, if proof is not possible, because of the construct X, point this out to the programmer. I like to compare this with: My_Real is digits 6 range 0.0...100.0; -- This is what I need, tell me if you cannot vs. double // This is what limits me, guess why. IMO, the first is the Ada way. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Randy Brukardt on 29 Jun 2010 15:28 "Peter C. Chapin" <pcc482719(a)gmail.com> wrote in message news:4c276114$0$2378$4d3efbfe(a)news.sover.net... .... > Also I find that when skimming program text just knowing that something > is conditional is sometimes enough for me to decide if I have to read it > more closely or not. If it says > > X := (if Rare_Condition then > Complicated_Expression > else > Complicated_Expression); > > I might be able to quickly tell which complicated expression I need to > look at without having to study both. Note that one advantage of conditional expressions is that they can avoid duplicating code. For instance, X(Index_Expression*Index_Base + 1) := (if Condition then Complicated_Expression else Other_Complicated_Expression); Probably is preferable to if Condition then X(Index_Expression*Index_Base + 1) := Complicated_Expression; else X(Index_Expression*Index_Base - 1) := Other_Complicated_Expression; end if; because it is much less likely to have a subtle error (like the second example I wrote above). I find that I write quite a bit of code of the second form, and I know I'd save time debugging if I had the first. Randy. P.S. But the resolution of conditional expressions is surprisingly complex. I think we've got it right, finally.
From: BrianG on 29 Jun 2010 21:19 Randy Brukardt wrote: > "Peter C. Chapin" <pcc482719(a)gmail.com> wrote in message > news:4c276114$0$2378$4d3efbfe(a)news.sover.net... > ... > Note that one advantage of conditional expressions is that they can avoid > duplicating code. For instance, > So, I guess for Ada'2w we can expect ++, --, +=, -=, and their brethren. That's the same argument that's always been used there. This is one case (maybe the first) I agree with Dmitry. It's an ugly addition. Maybe it's a good thing my current project is stuck on Ada'95. --Brian
From: Britt Snodgrass on 29 Jun 2010 23:21 On Jun 29, 8:19 pm, BrianG <briang...(a)gmail.com> wrote: > > This is one case (maybe the first) I agree with Dmitry. It's an ugly > addition. That was my reaction to seeing it. Its rather horrid to look at. > > Maybe it's a good thing my current project is stuck on Ada'95. > Yes, and I'll stick with SPARK. I expect future versions of SPARK will resist such weirdness. - Britt
From: Gautier write-only on 30 Jun 2010 00:09
On 29 juin, 21:28, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote: > P.S. But the resolution of conditional expressions is surprisingly > complex. I think we've got it right, finally. I can imagine - and probably it will be usual to come across code like : X( (if Condition_a then Expression_1a else Expression_2a) ):= Y( (if Condition_b then Expression_1b else Expression_2b) ); with Condition_b involving X and Condition_a involving Y, for instance... mmmh! G. |