On PEP 312: simple implicit lambda

[Christos TZOTZIOY Georgiou]

A little far-fetched, so please bear with me.

I would suggest that 'lambda-less lambdas' become code snippets instead
of actual functions... by code snippets, I mean something like
subroutines in the old BASIC way.  The reason for this is only
performance: avoiding a function call.  Read the seemingly off-topic
post and at the end I will make the connection to implicit lambdas.

Before bashing me for referring to BASIC, please note that there are
many places where we have to duplicate code; I know that the duplicate
code can be converted to a function call, but at the cost of losing
access to the local variables.

Take for example:

data = file_object.read(4096)
while data:
    # process here
     data = file_object.read(4096)

(In this simple case, the need to avoid duplication is not that strong,
so it is a bad example, but it's just an idea that popped up in my mind
a few minutes ago;  I won't stand up to it if proven to be stupid :)
There are cases with if...elif...else constructs where duplicate code is
used too, so if needed, I will find more examples.)

What I would do in such a case, would be the following:

<read_more_data>:
    data = file_object.read(4096)
while data:
	# process here
    <read_more_data>

The syntax I imagined is the one proposed above, with angle brackets and
all.  What happens is this:

1. The compiler finds a left angle bracket, followed by a valid
identifier, followed by a right angle bracket, folllowed by a colon.
The bytecode of the indented following statements is stored somewhere
else, probably appended at the end of the normal code object.  The
compiled bytecode ends with a RESUME opcode (not existant now).  In
place of the whole construct, the compiler issues a SNIPPET <address>
opcode (also not existant), which <address> will be filled in at the end
of the compilation cycle, kind of like JUMP_FORWARD arguments.  The
SNIPPET opcode, when executed, pushes the current "program counter" on
the stack, and uses the snippet address as the new "program counter".
The RESUME opcode pops the return address and stores it in the "program
counter".  No frame fiddling.
So at the point of definition, at runtime the code gets executed as
previously.

2. When the compiler finds a '<', identifier, '>' construct at the
beginning of a statement without a colon appended, it issues a SNIPPET
bytecode to the address of the code snippet.

3. The compiler does not allow duplicate definitions for a code snippet
identifier in the same namespace.  This is to avoid bugs.

4. The snippet identifiers are allowed and valid only inside the code
block they are defined in (eg a code snippet defined in a function is
unavailable to other functions, except for ones defined inside it).

5. Code snippets are not macros.  Plus, they should never be augmented
to accept any arguments.

6. Standalone code path alteration statements like 'continue', 'break',
'raise' should not be valid in a code snippet.

7. If the compiler sees a ':' at the beginning of an expression, the
following expression is stored and called as an unnamed code snippet
(just to avoid the function call overhead of a lambda).  This mechanism
cannot be used for deferred evaluation, though.

Now you can bash me to death :)
-- 
TZOTZIOY, I speak England very best,
Real email address: 'dHpvdEBzaWwtdGVjLmdy\n'.decode('base64')