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 27 Jun 2010 12:53 On Sun, 27 Jun 2010 10:35:02 -0400, Peter C. Chapin wrote: > 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); In comparable cases earlier Ada's choices were opposite: Complicated_Expression and then Complicated_Expression Complicated_Expression or else Complicated_Expression (Type with Complicated_List) > I might be able to quickly tell which complicated expression I need to > look at without having to study both. Do not use complicated expressions, that is the point! Note that you have to format the expression so that it looked like a normal if. What is the gain? It is unreadable when written as one line. It is as verbose as normal if when formatted. And it does not save you writing a function in real-life cases: File_Name := <add extension ".txt" if absent, do lower case, remove forward "./"> Argument (1); > Of course it all comes down to what one is used to. Dmitry says the > leading 'if' makes things harder to read, but I find his examples much > more difficult. If you like prefix notation, then why not: generic -- Built-in intrinsic generic for each type Type (<>) is limited private; function "if" (Condition : Boolean; Then, Else : Type) return Type; used as: if (A, B, C) if (A, then => B, else => C) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Peter C. Chapin on 28 Jun 2010 07:24 On 2010-06-27 12:53, Dmitry A. Kazakov wrote: > Do not use complicated expressions, that is the point! Note that you have > to format the expression so that it looked like a normal if. What is the > gain? As I mentioned before, I think the real point of the conditional expressions in Ada is to support the new pre- and post-condition features. My understanding is that statements are not allowed in that context. Sure involved cases might look like a normal if, but that's better than not being able to express a conditional at all. That is, the point of conditional expressions is not to somehow make the code shorter. 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. Peter
From: Georg Bauhaus on 28 Jun 2010 10:47 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.
From: Dmitry A. Kazakov on 28 Jun 2010 12:36 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 28 Jun 2010 13:04
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. 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. |