paren-free call expressions

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Wed May 18 13:33:35 PDT 2011


On 18.05.2011 20:16, Brendan Eich wrote:
> 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.
>

Yeah, right.

> Sure, block-lambdas are good as lighter functions too, but they're not 
> enough, and the TCP wins were considered losses in that context.

Sorry, TCP? What's that?

> 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.
>

Yeah, a casual "bidirectional" (up/down) closure.

> 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.
>

Just only if the receiving method doesn't define the block explicitly 
via the last &-argument. It's exactly the explicit block which is 
transformed to the Proc-object, and already this object can be returned 
upward. Though, there's no much sense in it, since the block is created 
lexically in the caller context and all caller's bindings are already 
closured in it anyway (will it be returned back or not -- no matter).

> 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().
>
>

Oh, of course. The same as in CoffeeScript. It will be a simple property 
reading, not calling. In Coffee we have to used () for calling a 
function without parameters. However in Ruby as is said there are no 
simple properties, all public stuff are _only_ methods. `foo.bar` -- is 
calling a method. `foo.bar = 10` -- is calling the method `bar=`, it's 
actually exactly parens-free mode of foo.bar=(10).

So in JS/Coffee I do not expect Foo.new behave as a method. But Foo.new 
{x: 10} -- yes, and it's very convenient for declarative DSL.

P.S.: so in proposal it will look like:

[1, 2, 3].map {|x| x * x}

not like this:

[1, 2, 3].map({|x| x * x});

right? (just asking to include to the following talk)

Dmitry.

>
>
> 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 <mailto: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/20110519/e052ed11/attachment.html>


More information about the es-discuss mailing list