optional "function" keyword

Russell Leggett russell.leggett at gmail.com
Thu Mar 8 05:37:32 PST 2012


Its mostly about being able to make control abstractions - being able to
make your own loops, conditionals, DSLs - and while you can get close with
anonymous functions, you'll never get there, because someone will want to
use 'return' or 'break' or 'throw' and the behavior is all screwed up (as
we all know).

OTH - if you call a TCO obeying block asynchronously and it calls return,
what happens? Does it throw an error? Is there a way to make that blow up
early (maybe not statically, but as part of passing the block to the
function in the first place?) If not, I fear you may add more confusion
than any gain you would get with TCP.

- Russ

On Thu, Mar 8, 2012 at 8:17 AM, Kevin Smith <khs4473 at gmail.com> wrote:

> (Slightly off topic...)
>
> In Yehuda Katz's examples (one of which I quoted) he's doing synchronous
> file stuff.  Which we don't really do in javascript.  Since so much of the
> code we write is asynchronous it seems like TCP return semantics are not
> really applicable.  Or are they?
>
> Thanks,
> kevin
>
>
> On Wed, Mar 7, 2012 at 8:31 PM, Kevin Smith <khs4473 at gmail.com> wrote:
>
>> (weighing in just as a developer...)
>>
>> So this is pretty consistent with the language and would be easy to
>> explain to current and future developers:
>>
>> // Short function, familiar rules:
>> () {
>>     // ..
>> }
>>
>> // Lexical this, tcp and all that
>> () => {
>>   // ..
>> }
>>
>> // Or
>> () => expr
>>
>> Pipes are fine in and of themselves, but IMO you get something that looks
>> like a frankenstien language:
>>
>> mtime: function() {
>>     // use the proposed block syntax, `{ |args| }`.
>>     this.withFile { |f|
>>       // in block lambdas, +this+ is unchanged
>>       var mtime = this.mtimeFor(f);
>>       if (mtime < new Date() - 1000) {
>>         // block lambdas return from their nearest function
>>         return "too old";
>>       }
>>       sys.print(mtime);
>>     }
>>   },
>>
>> "Fat arrows" are more aesthetically consistent and I feel like they will
>> be easier to explain:
>>
>> mtime: function() {
>>     // use fatty arrows
>>     this.withFile((f) => {
>>       // in block lambdas, +this+ is unchanged
>>       var mtime = this.mtimeFor(f);
>>       if (mtime < new Date() - 1000) {
>>         // block lambdas return from their nearest function
>>         return "too old";
>>       });
>>       sys.print(mtime);
>>     });
>>   },
>>
>> just my opinion...
>> kevin
>>
>>
>> On Wed, Mar 7, 2012 at 2:54 PM, Brendan Eich <brendan at mozilla.org> wrote:
>>
>>> Gavin Barraclough wrote:
>>>
>>>> On Mar 7, 2012, at 8:35 AM, Rick Waldron wrote:
>>>>
>>>>> Honestly, I'm starting to believe that most nay-sayers would get over
>>>>> block-lambda looking weird at first and learn to really love the benefit it
>>>>> provides. Sure they might say "it looks really bizarre", but they will also
>>>>> say "remember when we had to assign var that = this; or use bind()? The
>>>>> dark ages!! I love block-lambda!"
>>>>>
>>>>
>>>> I think there are more valid criticisms than the bizarre look alone.
>>>>  The block lambda syntax has the unintuitive restriction that only a subset
>>>> of expressions may be used in an initializer:
>>>>        {|a = b&c| a} // valid
>>>>        {|a = b&&c| a} // invalid
>>>> (This arises from the rule "BlockParameterInitialiser : =
>>>> BitwiseXorExpression", from http://wiki.ecmascript.org/**
>>>> doku.php?id=strawman:block_**lambda_revival<http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival>
>>>> ).
>>>>
>>>
>>> The obvious workaround: parenthesize. This is arguably small potatoes
>>> given parameter default values being new.
>>>
>>>
>>>  Using '|' to wrap arguments is problematic, given its existing usage
>>>> within the language.  There is a real advantages to a proposal that wrap
>>>> arguments in parentheses, such as "optional function" based ones on this
>>>> thread.
>>>>
>>> But (modulo separate "do" TCP proposal of yesterday) shorter function
>>> syntax is just syntax. No TCP, no lexical |this| in particular.
>>>
>>> Just replying to try to assign weights. The | vs. pdv issue is small
>>> IMHO. The incommensurate nature of block-lambdas vs. shorter functions
>>> hangs on TCP, which is big (bigger, anyway).
>>>
>>> /be
>>>
>>> ______________________________**_________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/**listinfo/es-discuss<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/20120308/c96d91b4/attachment.html>


More information about the es-discuss mailing list