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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
