Re: Gnat GPL 2010 available soon (conditional expressions)

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

On 6/27/10 2:12 PM, Dmitry A. Kazakov wrote:
> On Sun, 27 Jun 2010 03:55:02 -0700 (PDT), lekktu@gmail.com wrote:
>
>> On Jun 27, 10:37 am, "Dmitry A. Kazakov"<mail...@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? (:-))

I'd know readability of some particular syntax
from empirical evidence.  People read statements.
How many times do you hear someone shout, "Ouch, this is
conditional, I didn't notice at first!"  Cases in point are
when a declaration or a statement does not start with IF
but involves a conditional expression.  Compare alternative
solutions.[*]  (I believe Dilbert explains some kind of
WTF count for quality testing but I can't find it at the
moment.)

The situation is worse in the functional languages camp,
though. Whitaker's observations from the mid 1970s become
true again there, I think.

If you have to select software components by functionality
you must still accept it when each is written in some new
language, because ...  That's where Whitaker's observations
are relevant again, I think.

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.
More about the parens around the expressions in Kuchling's
comments, too.

Python also has

   [F(X) for X in I if P]

for list comprehensions, I being iterable.  No else part
is allowed here.  Compare

  [ F(X) : X in I | P ] of SETL

(or { F(X) ... } for set comprehensions) and

  [ F(X) | X <- I, P ] of Haskell.

There are more syntactic variations of the same concept of a
list comprehension in every journeyman's piece being added as
a new programming language to the list of yet another
functional programming language.   No one seems to ask
the question that had obviously been asked when Algol 60
was created: What is the abstract syntax for this and how
can we make a good, satisfying concrete syntax?  Based on
which criteria?

Python also has

  A and B or C

meaning the same as "B if A else C". This works because all
expressions can be used as Booleans.  Anyway, Python is said to
be consistent, probably because of the supply of rules
about proper contexts for using the word "if".  Now add to
that single rule set the requirement to use more than
one language during daily work, each of them equipped with
IF related idiosyncrasies.  Makes me mad.

If conditional expressions are needed, then at least let
the reader know that what is next is a conditional.
Ada uses the token sequence '(', IF for that.
Kuchling recommends parens for Python's conditional
expressions even when they are not strictly needed; they
are when sorting out associativity problems.

http://docs.python.org/whatsnew/2.5.html
This is the version of Python that programming Google
App Engine currently requires...

____
[*] Always important for for a language being capable of
drawing attention:
Is the equation "easy syntax" = "dumb and boring" true?
If so, we have to provide for some ASCII punctuation shuffling
in the grammar, because these are the characters that programmers
are capable of typing on their keyboards. There sole means of
distinction.
See MS's answer called F#, BTW...