Gnat GPL 2010 available soon (conditional expressions)
in [ADA]
|
Prev: Ann: Generic Image Decoder v.01
Next: ANN: Tables 1.10
From: Georg Bauhaus on 27 Jun 2010 04:04 On 6/26/10 11:42 PM, Dmitry A. Kazakov wrote: > On Sat, 26 Jun 2010 05:04:10 -0700 (PDT), lekktu(a)gmail.com wrote: > >> Well, it hasn't been hard to find the first bug. >> >> -------------------------------------------------------------------------------- >> function Validate (Dir : in String) return String is >> begin >> return (if Dir (Dir'Last) = '\' then Dir else Dir& '\'); >> end Validate; >> -------------------------------------------------------------------------------- > > [...] >> I'll submit a bug report. > > (Yes, to remove that abomination from the language! (:-)) > > I didn't read the AI, but your code looks very strange to me. Isn't its > syntax exposed to the infamous Pascal-if flaw? I mean, where is the "end > if"? Is this legal: > > (if A then X else if B then Y else Z) As the AI explains, you will need bracketing. WRT syntax, the Validate above example is OK for GNAT 2009 with -gnatX, but this GNAT wants constraints on the return value. And, yes, one may omit the "else branch" in a conditional expression if the result should be Boolean, thus implying True... Conditional expressions are supposed to remove the need for some single purpose functions, see the example in the AI lekktu has mentioned. Unlike the return object of a function, the value of a conditional expression cannot be renamed. A special purpose function in place of a conditional expression has to have a return object. We can't rely on effective inlining or on evaluation at compile time, either. If so, then in principle there is overhead. This is solved with conditional expressions. OTOH, we get the anonymity of conditional expressions, and an opportunity to deviate from Ada's principle of linear reading. But maybe the principle of linear has become outdated? John Barnes's integration example forces the reader up and down the nesting structure when reading, as do some container algorithms. And they make sense! So maybe conditional expressions deserve the same exception from a preference for linear reading? Consequently, conditional expressions will make Ada more attractive for programmers who still know the joys of clever programming constructs like syntactical inversion of control structure. Or who have been brought up with Lisp or Caml. If their modes of expression are not wanted on some project, the project can use additional source code analysis tools. These will complain when noticing nested conditional expressions, for example.
From: Dmitry A. Kazakov on 27 Jun 2010 04:37 On Sun, 27 Jun 2010 10:04:35 +0200, Georg Bauhaus wrote: > On 6/26/10 11:42 PM, Dmitry A. Kazakov wrote: >> On Sat, 26 Jun 2010 05:04:10 -0700 (PDT), lekktu(a)gmail.com wrote: >> >>> Well, it hasn't been hard to find the first bug. >>> >>> -------------------------------------------------------------------------------- >>> function Validate (Dir : in String) return String is >>> begin >>> return (if Dir (Dir'Last) = '\' then Dir else Dir& '\'); >>> end Validate; >>> -------------------------------------------------------------------------------- >> >> [...] >>> I'll submit a bug report. >> >> (Yes, to remove that abomination from the language! (:-)) >> >> I didn't read the AI, but your code looks very strange to me. Isn't its >> syntax exposed to the infamous Pascal-if flaw? I mean, where is the "end >> if"? Is this legal: >> >> (if A then X else if B then Y else Z) > > As the AI explains, you will need bracketing. Once I designed a language like that. It was out of necessity because that specialized language had only expressions. I also used brackets, but dropped "if", because you don't need it: (A then B [else C]) is syntactically unambiguous and easier to read. Anyway I do hate the idea, partially because I have been using that language for a long time. > Conditional expressions are supposed to remove the need for some single > purpose functions, see the example in the AI lekktu has mentioned. Single-purpose functions do not exist, likewise single-purpose types etc. Thinking of something in this way will give you a design/maintenance problem later. Ada was never designed to minimize up front thinking and typing in mind. > Unlike the return object of a function, the value of a > conditional expression cannot be renamed. A special purpose > function in place of a conditional expression has to have a > return object. We can't rely on effective inlining or on > evaluation at compile time, either. can you rely on what the compiler does for if-expressions? Come on, that is a silly argument. If inlining is a problem add pragma Enforced_Inline. > OTOH, we get the anonymity of conditional expressions, and > an opportunity to deviate from Ada's principle of linear reading. towards the principle of no reading? Write and rewrite, but never read what you wrote... > Consequently, conditional expressions will make Ada > more attractive for programmers who still know the joys of > clever programming constructs like syntactical inversion > of control structure. Sorry, if I misunderstood you. Do you seriously mean that the goal of language design is attracting some people? > If their modes of expression are not wanted on some project, > the project can use additional source code analysis tools. > These will complain when noticing nested conditional expressions, > for example. In C projects you can use lint. Does it make the design of C any better? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: lekktu on 27 Jun 2010 06:55 On Jun 27, 10:37 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > dropped "if", because you don't need it: > > (A then B [else C]) > > is syntactically unambiguous and easier to read. As you can see on the relevant AI, this was in fact considered (among lots of other things). FWIW, I'm quite glad they went for the 'if', to me it is *much* easier to read.
From: Dmitry A. Kazakov on 27 Jun 2010 08:12 On Sun, 27 Jun 2010 03:55:02 -0700 (PDT), lekktu(a)gmail.com wrote: > On Jun 27, 10:37�am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >> dropped "if", because you don't need it: >> >> � �(A then B [else C]) >> >> is syntactically unambiguous and easier to read. > > As you can see on the relevant AI, this was in fact considered (among > lots of other things). FWIW, I'm quite glad they went for the 'if', to > me it is *much* easier to read. How do you know it? (:-)) BTW, in my language I also have a bracketless [infix] form: B when A else C where "when" and "else" are true infix operators. The above is associated as: ((B when A) else C) The semantics is that B when A is B when A is true and undefined when A is false. X else C is X when X is defined and C otherwise. This is a bit easier to read, because of its symmetry. But so far I saw no readable syntax for conditional expressions and I doubt that it existed. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Peter C. Chapin on 27 Jun 2010 10:35
On 2010-06-27 09:42, Georg Bauhaus wrote: > Python has your syntax, too, though it didn't from the start, > see about PEP 308, where Kuchling writes, "so the order of > evaluation jumps around a bit": The expression > > B if A else C > > places the controlling expression in the middle of > what it is controlling. This placement seem obvious when > painting program trees but we are writing programs on single > lines. When you read linearly, IF will signal that some > case distinction is coming. When IF appears after what > it is controlling, you are reminded that what you have > just been reading is actually conditional on some program > text to follow next. And maybe there is going to be some > other thing for the other case. Or maybe not. For what it's worth, I agree that the syntax with the leading 'if' is much more readable to me than the alternatives presented here so far. For one thing (if A then B else C) seems pretty widely used by functional languages (OCaml, Haskell, Scala, even Lisp after accounting for Lisp's general syntax). It also reads well in English, which is true of other Ada constructs. In any case I want to know up front that what I'm about to read is conditional. If I have to first read over some (potentially complex) expression before I come to the syntax that signals the conditionality of the construct, I will end up back tracking and reading the expression again. 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. But with something like X := (Rare_Condition then Complicated_Expression else Complicated_Expression); Hera at a first glance it looks like the assignment to X is all about Rare_Condition. Something like X := (Complicated_Expression when Rare_Condition else Complicated_Expression); Is even worse. Not only does it look like the assignment is about the first complicated expression, I will probably end up studying that expression before I even realize that is only rarely evaluated. 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. Peter |