Function Syntax

Brendan Eich brendan at mozilla.com
Thu May 12 15:31:17 PDT 2011


Don't worry, no fisking (bottom-citing instead :-P).

This topic of "let's switch to bytecode" or "let's abstract a VM" has come up before:

http://apps.ycombinator.com/item?id=1893686

IMHO Java's bytecode did not help, it hurt. It hurt Java's evolution, in big ways -- often just by keeping compatibility when breaking compatibility was required (and compatibility was broken later anyway). It hurt VM implementation and optimization.It hurt users who had to compile and package all the time -- during development in particular (yes, people minify JS when deploying, but that's not the javac/jar pain point). I think bytecode helped kill Java on the client.

In similar big ways, and others that I won't rehash (see http://brendaneich.com/2007/03/the-open-web-and-its-adversaries/), the opacity (at least until recently) and even *multi-generation VM* bytecode sub-formats of SWF has hurt Flash.

Some think Native Client will save us. I read http://cananian.livejournal.com/63325.html and see great research, but nothing any browser save Chrome might ship, let alone standardize. DLL hell, libc version hell, svn branch feature-conflict hell, ARM vs. x86 etc. hell (PNACL has not saved us; LLVM bitcode is not always arch-independent), and on and on. This stuff is 10x to 100x more complex than JS to specify in a standard and implement interoperably.

And that's the main argument for JS over bytecode, beyond the distortions of lowering to bytecode, freezing the bytecode, trying to evolve languages and VMs thereafter: that JS is strictly much simpler, orders of magnitude simpler, than a language VM. Especially a language-"neutral" VM.

(ECMA-334 and -335? Don't even try those on me.)

/be


On May 12, 2011, at 3:09 PM, David Foley wrote:

> 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" <dmitry.soshnikov at gmail.com> 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 &parameters:
>>> 
>>> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110512/f2b3f7ba/attachment.html>


More information about the es-discuss mailing list