Detecting the trivial can be non-trivial (was Why not allow empty code blocks?)

[Rustom Mody]

On Saturday, July 23, 2016 at 4:44:00 PM UTC+5:30, Marko Rauhamaa wrote:
> Steven D'Aprano :
> 
> > On Sat, 23 Jul 2016 01:33 am, Kent Tong wrote:
> >> I'm aware that we can use 'pass' as an empty code block. But why
> >> doesn't python allow a code block to be empty and thus eliminate the
> >> need for this null statement?
> >
> > Because it cannot tell the difference between an empty code block and
> > failing to indent the code block:
> >
> > for x in sequence:
> > print('loop')
> >
> > Is that meant to print 'loop' each time around the loop, or just once, at
> > the end of the loop?
> 
> I don't see an ambiguity: obviously the print call takes place after
> finishing the loop.
> 
> > There are cases where the interpreter could tell:
> >
> > if flag:
> > else:
> >    block
> >
> > Obviously the "if" block is empty. But for consistency, and
> > simplicity, the interpreter requires a pass there too.
> 
> I wonder if there is any true case of ambiguity. I guess this is all
> about an enforced aesthetic principle: GvR doesn't like the looks of an
> empty block.
> 
> > One less thing to be programmed, one less thing for the user to
> > remember. Just require pass any time you have an empty block, rather
> > than try to remember where it is required and were it is optional.
> 
> Actually, the requirement of a dummy statement is a slight annoyance for
> the programmer. After deleting a statement, you must see if you have to
> put in a pass statement. And after adding a statement, you may feel the
> urge to remove the redundant pass statement.

Tsk Tsk…
The Europeans took 500 years to appreciate that zero is a necessity
https://en.wikipedia.org/wiki/Arabic_numerals#Adoption_in_Europe

Do you seriously suppose that they did not have the asymptotic/limiting case of:

There are 3 apples in the basket
There are 2 apples in the basket
There are 1 apples in the basket

Now you can (and they probably did) replace the ‘1’ by ‘no’
But that’s not a number
You can have nothing there:
There are   apples in the basket
Is it visible?

Problem is more evident if we use a ‘base-1’ system
There are XXX apples in the basket
There are XX apples in the basket
There are X apples in the basket
There are  apples in the basket

IOW the notion of zero is trivial enough (in hindsight)
First-classing it as a notation is not at all trivial

This question is analogous – maybe almost identical – to the question of
the most trivial automata/regex etc.

For a long time the re → dfa transformation went and was taught the laborious
route:
re → nfa-with-ε-transitions → nfa-without-ε-transitions → dfa

https://en.wikipedia.org/wiki/Thompson's_construction
https://en.wikipedia.org/wiki/Powerset_construction

Now there is a direct, straightforward method which only becomes available
 (thinkable) when we have a null regular expression:
https://drona.csa.iisc.ernet.in/~deepakd/fmcs-06/seminars/presentation.pdf

Coming back to zero:
While it is true that European civilization knew of and ignored the zero for
500 years and science-advances happened only after adopting zero, and today
we take it for granted. Still it remains true that zero is a bit anomalous.

Some evidences of this:
Lets say that a numeral is in normal form if it has no leading zeros.
So 0025 normalizes to 25.

Is 0 a normal form?

Likewise: Early versions of Fortran had loops that could not execute zero times:
http://www-pnp.physics.ox.ac.uk/~gronbech/intfor/node18.html

In the same vein «pass» (Dijkstra called it «skip») and «abort» (roughly «raise Exception» in python-speak) correspond to 1 and 0 in numbers

And IMHO anyone who rejects the search/formalization for the trivial case as a 
useless activity is effectively pushing us back to the dark ages.
And if one finds it hard to believe that humans can be incredibly resistant
to learning from mistakes, here's a list of long-lasting errors like rejecting zero:
http://blog.languager.org/2016/01/how-long.html