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