paren-free call expressions

Brendan Eich brendan at mozilla.com
Wed May 18 09:16:28 PDT 2011


I'm working on a block-as-better-function proposal, essentially an alternative to arrow-function-syntax even though unlike the latter, the former has new semantics.

One of the insights from Allen and Mark, which is kind of obvious to Rubyists, is that blocks as lightweight functions usable for building control abstractions really need paren-free calls to be as light as in Smalltalk, therefore actually usable compared to writing loops or even old-fashioned function expressions.

Sure, block-lambdas are good as lighter functions too, but they're not enough, and the TCP wins were considered losses in that context. This is because a function can escape from a downward flow and later be invoked, then attempt to return from the activation of its static parent function after that function's activation has been deallocated.

A block may not escape. Indeed Ruby's simplest downward-funarg block protocol involves caller passing a block via  a paren-free call, and the receiving method not declaring the formal, rather just calling it via Ruby's yield. No escape.

Anyway, I'm going to include paren-free call syntax in the block-lambda proposal, not factor it out. It probably could be, but it's not as simple as you show. In particular,

  foo = Foo.new

in Harmony should continue to get the 'new' property from Foo and assign it to foo. It should not implicitly call Foo.new().

/be


On May 18, 2011, at 8:53 AM, Dmitry A. Soshnikov wrote:

> Hi,
> 
> Parens-free call expression allow to provide some actions decoratively. From this, the consequence of easy and elegant DSLs (domain specific languages). For example:
> 
> class Account {
>     attributes "customer", "cart"
> }
> 
> Thus, call to `attribute` function looks like not the imperative call, but like a declaration that instances of Account class has those attributes.
> 
> Ruby uses exactly this approach of its attr_accessor, private, etc. "keywords" which in fact are just functions placed on the very basic class:
> 
> class Foo
>   attr_accessor :x, :y
> end
> 
> foo = Foo.new
> 
> foo.x = 10
> foo.y = 20
> 
> which in fact is just a syntactic sugar (not at grammar, but at application level via simple `attr_accessor` function) for the:
> 
> class Foo
> 
>   def x
>   end
> 
>   def x=(value)
>   end
> 
>   def y
>   end
> 
>   def y=(value)
>   end
> 
> end
> 
> That is, create getter and setter for every needed property (yes, in Ruby all public properties are accessors). Thus, this function does it behind the scene: attr_accessor(:x, :y), however being called without parens, it elegantly looks like a declarative keyword. Another example as is said, `private` function which also without parens looks like an operator.
> 
> Besides, If -> will be accepted, in many cases (being passed as callback) they will much more elegantly look without parens of call expressions.
> 
> So what do you think? If the idea is good, may it bring some problems with parsers and grammar?
> 
> P.S.: some examples of declarative DSLs: https://github.com/jashkenas/coffee-script/wiki/%5BExtensibility%5D-Writing-DSLs
> 
> Dmitry.
> 
> _______________________________________________
> 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/20110518/9f5de81e/attachment.html>


More information about the es-discuss mailing list