On Mon, Mar 03, 2014 at 11:03:03PM -0800, Andrew Barnert wrote:
On Mar 3, 2014, at 22:02, David Townshend <aquavitae69@gmail.com> wrote:
What about a new code literal object, e.g.
thunk = c'x + 3'
Off the top of my head, I think that looks alright.
thunk(x=2)
I'm not entirely sure about that. That basically makes these thunks just a function. I'm still not quite sure how this should actually be used in practice, so as far as I'm concerned this is just pie in the sky thinking aloud. If thunks are just functions, why not make them functions? There needs to be something extra (different scoping rules, faster/more lightweight, *something*) to make the idea worthwhile. I think I need to learn more about Algol and other languages that use call-by-name and thunks. I may be completely on a wild-goose chase here, but I'm surely not the only person who has needed to delay evaluation of an expression. http://en.wikipedia.org/wiki/Thunk
Why does it need to be built from/look like a string? I think it would be just as simple for the parser, and simpler for editors, and less misleading for readers, if it used a different marker.
Not that I'm seriously suggesting backticks here, but...
thunk = `x + 3`
Actually I'd be happy with backticks, but Guido has said No Backticks Ever Again. So until the Glorious Revolution, we're stuck.
Meanwhile, if this gives you a code object, what do you do with it? Using eval on something that looks like a string but isn't may be correct to anyone who understands Python deeply, but I think it could be very misleading to anyone else. And creating a FunctionType from a code object is pretty ugly for something that deserved literal support...
Agreed. What I have in my head is some vague concept that the Python evaluation rules will somehow know when to evaluate the thunk and when to treat it as an object, which is (as I understand it) what happens in Algol. Again, just thinking aloud, perhaps we do this: thunk = `some_expression` # delays evaluation a = [0, 1 + thunk] # evaluates thunk in the current scope b = [0, `1 + thunk`] # delays evaluation and creates a thunk object # equivalent to `1 + some_expression` c = b[1] # now evaluates the thunk object d = f(2, thunk) # evaluates thunk in f's scope e = g(3, `thunk`) # passes the un-evaluated thunk object to g Consider this just a sketch, and in no way fully thought out. (This will most definitely need a PEP.)
Triple quotes could also be used to support multiline code blocks.
That is one advantage of reusing strings. In fact, that gives us a way to embed statements in the middle of expressions. Which I'm not sure is a good thing.
I have little interest in allowing thunks to be statements. If you want a delayed statement, use compile and eval. Or def. (But maybe that applies to expressions too?) Did I mention this needs a PEP? -- Steven