[Python-ideas] Syntax: 'return: ...' expressions

[Andrew Barnert]

On Jan 7, 2015, at 17:05, Yawar Amin <yawar.amin at gmail.com> wrote:

> On 2015-01-07 11:20, Yawar Amin wrote:
>> On 2015-01-07, at 2:11, Andrew Barnert <abarnert at yahoo.com> wrote:
>>> [...]
> 
>>> That's the key. A function is a way to wrap a sequence of statements
>>> (the function body) so it can be used in an expression (a function
>>> call). Because JavaScript lets you define functions (with full
>>> statement syntax) in expressions, that gives you a way to "demote" an
>>> expression inline, while Python can only do so out-of-line. At the
>>> core, this is what all of the multiline lambda attempts and similar
>>> proposals are trying to accomplish.
>> 
>> Thanks. This has given me an idea that's on a slightly different
>> tangent than this one. Will write it up (this time with some actual
>> runnable code) when I get home tonight.
> 
> As promised, a write-up of my idea:
> http://yawar.blogspot.ca/2015/01/expressive-functional-programming-with.html
> 
> I have a feeling that some Pythoneers will really hate it, but hey, what
> can you do :-)

Well, I think you've successfully proven that for imperative-style code, a statement-expression language is more readable than a CPS pure-expression language. :)

The difference isn't just a lack of syntactic sugar: in a pure expression language, "is followed by" has to be modeled as "is controlled by" (with CPS that's made explicit), meaning (in Python) it has to be indented. 

Haskell's do statement has a nice way out of that (if you really want to turn off Pythonistas by using the word "monad"). Promise-based sequencing (as with most JS Promises/A-based code) offers a different solution with a similar effect. It might be worth following one of those ideas to see where it leads you.

In fact, the latter raises another possibility: once you're yielding from promises, you've got coroutines for free. In at some cases, explicit CPS code can be turned into implicit coroutine code very easily. If that works for everything, it also means you no longer need the manual trampoline and/or you can make all of your sequencing asynchronous and therefore add in concurrency for free (as in asyncio).

Another trick that might be worth playing with explicit native globals and locals for your functions (e.g., by constructing a new types.FunctionType), so let bindings (which also take care of def, by just binding a lambda, and class, by binding a call to type or the appropriate metaclass) can use native Python environments (and closures). This would be more interesting if you wanted to add state later (because you'd get it for free), but it might be interesting just to see where you run into problems.

Anyway, while this raises some interesting ideas, I don't think it raises any ideas for the future of the Python language, so I'm not sure Python-ideas is the right place to discuss it.