On 04Mar2014 17:23, David Mertz firstname.lastname@example.org wrote:
On Tue, Mar 4, 2014 at 4:06 PM, Cameron Simpson email@example.com wrote:
On 04Mar2014 17:57, Ryan Gonzalez firstname.lastname@example.org wrote:
Only problem is that it looks a tad perlish...Of shellish.
But worse, does nothing even remotely loke what that does in perl or shell (or basic or...).
I think I could be +0 for a bit different spelling that *is* actually shell-ish. I.e. as a way to handle snippets, this doesn't seem so bad:
foo = 1 a = $(foo + 1)
Definitely nicer. Still irrationally uncomfortable about the "$" though.
A thought, though it could break existing code (and nested tuples, alas):
a = (( foo + 1 ))
Still, what does this mean?
a = 3 + (( foo + 1 ))
I think that would need to be a syntax error, because I can't see it being anything except nonsense otherwise.
That makes me think the (()) or $() is in the wrong place. Maybe:
a := foo + 1
Hmm. hasn't that one already come up?
b = eval(a) * 6
This makes me unhappy. Eval parses a string and runs it, currently. I would _want_ to read that as "compute a, then eval() the result".
I would prefer the occurence of "a" in an expression to cause it to be evaluated then, much as happens already. It does mean that there would be "silent" evaluation bombs lurking in expressions. For example, given a doubly linked list (to make the "reference" stuff glaring):
node.right = node2 node2.left = node
If node or node2 were thunks, this would be surprising to the reader. Of course, we can surprise the reader already with __getattr__ etc.
But I think it would be better if:
b = a
just made "b" a reference to the same thunk as "a".
Since I'm cavilling about "eval", how about just treating thunks like other functions (which is how we spell code to be run later presently) and have them be callables. So your "b = eval(a) * 6" would just be:
b = a() * 6
That way it is glaringly obvious that "a" happens now, rather than earlier.