On Tue, Mar 4, 2014 at 4:06 PM, Cameron Simpson <cs@zip.com.au> wrote:
On 04Mar2014 17:57, Ryan Gonzalez <rymg19@gmail.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.

--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.