On 03/04/2014 07:05 PM, Andrew Barnert wrote:
On Mar 4, 2014, at 14:31, Greg Ewinggreg.firstname.lastname@example.org wrote:
Steven D'Aprano wrote:
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.
But Algol has the benefit of static typing -- the procedure being called explicitly declares whether the argument is to be passed by name or value. Python has no idea about that at compile time.
This is the main reason I think it's more productive to think of this in terms of Lisp-style quoting than Algol-style thunks. The fact that quoting/thunking gives you a code object instead of an AST (sexpr) is not significant here* (unless we're also considering adding macros). The fact that it gives you a first-class value, and that we can't use the "implicit casting" syntax that comes with static typing to magically evaluate the object at the right time, is critical.
This is basically the same problem I described trying to implement Boost-style auto lambdas in Python without C++-style implicit cast from lambda to function.
In a experimental language I'm writing, I use a concept I call "Context Resolution" to resolve objects to expected kinds of objects. The expected type/kind is determined in the context of how things are used together rather than by how they are defined. (That allows everything to be objects). Keywords, Names, Expressions, and CodeBlocks, etc...
In python it would probably depend on AttributeError instead of the type.
If an object doesn't have the needed attribute, then it could try calling a different method, possibly __resolve__. Then retry the attribute lookup again on the result.
If there's no __resolve__ attribute, then the AttributeError would be raised as usual. The chained __resolve__ resolution attempts would also give a useful exception backtrace.