On Tue, Mar 4, 2014 at 4:06 PM, Cameron Simpson firstname.lastname@example.org wrote:
On 04Mar2014 17:57, Ryan Gonzalez email@example.com 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 was going to remark that in my mind I would always see:
a = $foo + 1
and (1) mentally bind the "$" to "foo" alone, not treat it as a prefix to the whole expression and (2) expect "a" to evaluate right now, regardess.
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) b = eval(a) * 6 c = $(foo + a/2) print(c, eval(c)) # <thunk object at NNNN> 2 print(a + 1) # TypeError, incompatible types for '+' operation, thunk and int
That is, the whole "thunk" or really just "code-snippet" could be a shorthand way to refer to a segment of (dynamically scoped, basically) code we might use in different places. It's a lot like Ruby blocks, of course, but the difference is that it's not only in the final position of a call, but anywhere anything might be used or passed.
On the other hand, this isn't *really* different from just putting snippets in strings like we can do now. The one difference I envision is that maybe these "thunks" would be completely resolved by an eval(), unlike a string. That is, 'c' is a thunk, but it's a thunk that contains another thunk. So the eval() function becomes a recursive-unthunk.
Well, maybe I'm -0 rather than +0. I'm definitely -1 on the "thunks taint all expressions" approach suggested initially, which seems far too magical and implicit.