You know what? As a pragmatic programmer, one who tries their best to translate problem domains into normative business logic in a language with a sufficient level of expressiveness to accommodate manageable adaption to moving goals, the language should not be the problem domain.
As far as I have so far understood it, this list is about the evolution of JavaScript. (Personally I prefer it's original designation as LiveScript, and the affordances it allowed to move from scratch code to mature application delivery). I am most likely going to regret saying this, but I would feel (yes, actual emotion') like a coward if I didn't make this point. There appears to me, to be too much focus on the interpretation of the language, and the technical challenges therein, rather than than the business hours affordances of the language to deliverables and developer experience of the language. However, what if, rather than trying to consolidate legacy with emerging (naive or otherwise) expectations of the languages evolution, that focus is put instead upon a polysemetic interpreter, a common VM, which language authors can utilise to their own ends (within constraints), whereby the principles of JavaScript dynamism define it's operational boundaries. In essence, what I'm proposing, is rather than JavaScript being the sole glue of the web, that instead focus is put upon a programmable standardised vm design, which can accommodate JavaScripts evolution. That way we can focus on interpreter specifics, and language design, without the politics. As I said, I know I will probably regret this, and Brendan, I know I wouldn't survive a point by point break down (really, this is a high level philosophical proposal, not a technical one), but at least this path could (potentially) be a sound vehicle to distinguish the natural evolution of this particular language, from the needs of developer teams producing sophisticated highly interactive client side web applications (JavaScript could be the Rosetta stone). I am genuine trying to be constructive here, for better or worse, and I know that casual subjective opinions are not necessarily welcomed here, but that's my tuppence all the same. If this mentality is anathema to the group, and if anyone is open to discuss this strategy lest we pollute this list, feel free to get in touch Best Dave David Foley | Senior Software Architect +353 87 667 4504 Skype: david.d.foley On 12 May 2011, at 22:51, "Dmitry A. Soshnikov" <[email protected]> wrote: > On 13.05.2011 1:25, Brendan Eich wrote: >> >> On May 12, 2011, at 1:06 PM, Brendan Eich wrote: >> >>> On May 12, 2011, at 10:55 AM, Brendan Eich wrote: >>> >>>> Ruby is far from simple, btw. Check out >>> >>>> >>> >>>> http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby >>> >>>> >>> >>>> and the wikipedia page it references. >>> >>>> >>> >>>> Looks like Proc.new but not lambda can return from its caller. >>> >>> From http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Method_Calls it >>> should be clear I was missing the "block" target. Blocks are syntactically >>> restricted to being downward funargs. Only if reified as Procs do they >>> potentially escape to be called later when their lexical parent method >>> could have already returned. >>> >>> IOW, blocks are restricted to being downward-funargs by syntax at their >>> expression site, and by default in the callee (without the & before the >>> corresponding formal parameter). >> >> To say a bit more about this, here's a demo of the downward-only-funarg >> nature of blocks passed as extra trailing arguments, with no matching >> ¶meters: >> >> def say >> puts yield "world" >> end >> >> def say_hello >> say {|x| "hello #{x}" } >> end >> >> say_hello >> >> The output is "hello world" of course, but Ruby's yield calls the block >> without it escaping as a reified Proc that could be invoked later, after the >> downward flow. Neat! >> >> (Rubyists, please correct anything wrong here.) >> > > If the block is described explicitly in the method definition (that is, the > last parameter with &) then it can be returned back as a result: > > def foo &block > > if block_given? > > yield 10 # call the block implicitly > > block.call 20 # the same, but explicitly > > block # return the block back > > end > > end > > # pass the block downwards, > # and get it back (upwards) as a result > > returned_block = foo { |i| print i } > > # and call it again > returned_block.call 30 > > Though, there's no much practical sense in this, since the block lexically is > created in the global context of (in this case particular case) and captures > its bindings, it, obviously isn't related with bindings of callee. > > Brendan, take a look at this detailed source-article explanation of closures > in Ruby http://innig.net/software/ruby/closures-in-ruby.rb (it's executable > file, so a good tutorial). There all this stuff with blocks, etc is explained > well. > > P.S.: damn, it's so sorry that I haven't much time now to be involved deeply > into the recent discussions of shorter function syntax. I hope I'll read > carefully those threads later. A one thing I'd like to mention, we should not > afraid of changes even if they syntactically aren't so familiar and habitual > as were in Java. > > P.S.[2]: > > -> syntax is / was long time before CoffeeScript. It's just a standard math > definition of a function, it's used as a type of a "function" -- lambda > abstraction -- in the lambda calculus, that is the "arrow type". It's used in > many other langs, e.g. Erlang (which I use in my current job), Haskell, > other. So, don't afraid it. Though, the issues with hand-written LL parsers > should be also considered. > > Dmitry. > >> I'm not suggesting we copy any of this, just passing along my Ruby-n00b >> knowledge. >> >> >>> When we considered lambdas (the "Allen's lambda syntax proposal" thread >>> from late 2008 to early 2009), we did not try to confine them syntactically >>> to actual parameter lists. Did we miss a key restriction or feature of >>> Ruby? I'm not sure, I'm too much a Ruby n00b. >> >> If blocks could not escape to be called after their enclosing function had >> returned, then we would overcome the objection raised last time, articulated >> best by Maciej: >> >> https://mail.mozilla.org/pipermail/es-discuss/2008-December/008390.html >> >> But Ruby went all the way, allowing a block to grow into a Proc and outlive >> the method in which the block was expressed. I expect similar "ecological >> pressures" to apply if we added blocks only as downward-funargs. >> >> Plus, we'd still want shorter function syntax, not just blocks as >> downward-only funargs (however nice for map, forEach, etc.). >> >> I will write up a block strawman, to give it a fair shake along side >> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax. >> >> /be >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
