Re: Gnat GPL 2010 available soon (conditional expressions)

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 6/26/10 11:42 PM, Dmitry A. Kazakov wrote:
> On Sat, 26 Jun 2010 05:04:10 -0700 (PDT), lekktu@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.