Why not allow empty code blocks?

[BartC]

On 31/07/2016 03:10, Steven D'Aprano wrote:
> On Sun, 31 Jul 2016 04:46 am, BartC wrote:

>> No named loop variable to invent, create, maintain, and destroy. No
>> range object to create, destroy etc. If you're looking for ways for a
>> language to be more efficient, then why disregard this possibility?
>
> Who says I've disregarded it? Just because I've concluded that the benefit
> fails to outweigh the costs doesn't mean I didn't think about it.

The costs are near zero: at minimum, a syntactic construct such as:

  repeat N:

that expands to:

  for _ in range(N):

The benefit is not so much performance, but being able to express 
something very easily and quickly.

> (2) And even if it is significant, surely that's something that a keyhole
> optimizer can detect without requiring the user to care one iota about the
> difference? And indeed, that's EXACTLY what Python 3.6 (and probably older
> versions) does: it optimizes out the comparison, and unconditionally loops:
>

> py> dis("while True: spam()")
>   1           0 SETUP_LOOP              10 (to 12)
>         >>    2 LOAD_NAME                0 (spam)
>               4 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
>               6 POP_TOP
>               8 JUMP_ABSOLUTE            2
>              10 POP_BLOCK
>         >>   12 LOAD_CONST               0 (None)
>              14 RETURN_VALUE

In Python 2.7, the True value has be tested each time.

The reason? Because True is one of those names that could be reassigned 
by the programmer. This was the subject of the discussion we had some 
time back about not being able to assume anything, because anything 
could change.

In Python 3, True wisely seems to have been turned into a reserved word. 
With the obvious benefits of the compiler always knowing what's what!

>> But dedicated forms (even if they just map to 'while' or 'for') wouldn't
>> hurt. Syntax is free after all, and it's about expressing exactly what
>> you mean.
>
> Syntax is not free!
>
> Syntax requires more code in the compiler. Somebody has to write it,
> somebody has to maintain it, somebody has to test it, somebody has to
> document it.

For language implementations, dedicated syntax is by far the easiest 
thing to code. Far easier that trying to detect certain patterns in the 
code later on.

> Every little feature increases the size of the compiler, both the source and
> binary, and increases the chances of compiler bugs.

Support for dedicated endless loops is around 20 lines in my compiler:

http://pastebin.com/wXXVQFkJ

(Plus 3 or 4 more lines distributed elsewhere.)

The first function is to parse the loop. The second to generate code, 
which is more complex because it supports extra loop controls which 
don't exist in Python.

> There are already
> situations where compilers are too big (e.g. on embedded devices, or
> memory- and storage-constrained machines like the RaspberryPy).

Are you serious? The Pi (even the first one that I've got lying around 
somewhere) has hundreds of MB of memory, a clock speed of 700MHz, and 
storage measured in GB.

My entire bytecode compiler is less than 0.3MB (and that includes all 
sorts of crap).

  It adds to
> the time it takes to download,

LOL!

The Anaconda I was recommended to download last year (when I just wanted 
numpy) was over 1GB.

While even my ordinary Python 3 installation has 5000 files.

I repeat, adding a bit of extra syntax to a language is utterly trivial 
by comparison.

(Not quite so easy in an existing, established language, but that's 
another matter. But it does sound as though, even if we were discussing 
a totally new language, you still wouldn't be interested in such features.)

-- 
Bartc