simple shorter function syntax

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Mon Jul 26 00:16:23 PDT 2010


On 26.07.2010 3:57, Maciej Stachowiak wrote:
>
> On Jul 24, 2010, at 11:51 AM, Mark S. Miller wrote:
>
>> On Fri, Jul 23, 2010 at 10:37 AM, Oliver Hunt <oliver at apple.com 
>> <mailto:oliver at apple.com>> wrote:
>>
>>
>>     On Jul 23, 2010, at 10:32 AM, Brendan Eich wrote:
>>
>>     > On Jul 23, 2010, at 10:27 AM, Oliver Hunt wrote:
>>     >
>>     > [Good point about LL(∞) snipped.]
>>     >
>>     >> *  To give you an idea of how important parsing is, the 280
>>     North folk once told me that parsing made up 25% of the load time
>>     for 280 Slides.
>>     >
>>     > Ollie, was that with browser-side Objective-J compilation, or
>>     with the server translating and feeding the Obj-J-lowered-to-JS
>>     code to the browser?
>>
>>     I believe it was with the browser being passed preprocessed
>>     source, but i'll harass them to find out.
>>
>>     > I have polled audiences at talks in the last year about shorter
>>     function syntax, see first two links at
>>     http://brendaneich.com/presentations/. Results mainly for fun but
>>     somewhat informative (to me at any rate) were not resoundingly in
>>     favor of a new and much shorter keyword to use instead of function.
>>     >
>>     > This was before
>>     http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
>>     was proposed, so I didn't ask the audiences to clap for its # syntax.
>>     >
>>     > People like the expression-closure idea, although syntax needs
>>     to be hammered out. See
>>     https://developer.mozilla.org/en/new_in_javascript_1.8#Expression_closures_%28Merge_into_own_page.2fsection%29
>>
>>     I personally am not too fussed about the reduced typing -- if
>>     people really wanted reduced typing we could simply adopt "\"
>>     which seems to be the common symbol used for a function.
>>
>>
>> The reason I prefer "#" to "\" is simply that JavaScript source text 
>> [fragments] frequently appear in literal strings. Right now, the only 
>> quoting hazard this introduced is quotes and backslashes in nested 
>> literal strings. (Is this true?). If you use backslash in syntax 
>> elsewhere in the language, then it becomes an additional quoting 
>> hazard that's easy to miss.
>>
>> +1 on "#".
>
> Good point about the escaping hazard. I think # may look funny to 
> people because it is a "noisy" symbol and also because it is a comment 
> delimiter in many languages. Two other characters totally disallowed 
> in the syntax are @ and `, I wonder if either of those would be more 
> visually pleasing:
>
> [0, 1, 2, 3].map( #(x) {x * x} )
> [0, 1, 2, 3].map( `(x) {x * x} )
> [0, 1, 2, 3].map( @(x) {x * x} )
>
> I also wonder if using a strictly binary operator might be workable 
> without creating syntax ambiguities:
>
> [0, 1, 2, 3].map( ^(x) {x * x} )
> [0, 1, 2, 3].map( *(x) {x * x} )
> [0, 1, 2, 3].map( %(x) {x * x} )
>
>
> I kind of like ` but it may be too visually subtle and may be 
> confusing to lisp users. @ seems less visually harsh than #. I like ^ 
> for resemblance to lambda, overall visual weight, and alignment with 
> Apple's "blocks" extension to C[1]. I have a vague memory that we 
> discussed ^ before and discarded it, but I can't find that discussion 
> in the archives at the moment.
>

Is it RegExp? Or ASCII-art maybe? Or modern smiles? Looking on all this, 
I already think that old "function" is not so bad.

The thing is not to invent some "cool" symbol for that. The thing is to 
make convenient short notation which /at the same time/ will reflect a 
/human-read function/ concept -- a function from math and programming. % 
- what is this?

The good thing of JS, that it (in contrast with all those Python, Ruby, 
Erlang, etc) has _the same_ syntactically definition of a /casual 
subroutine/ -- a function declaration (FD) and a /"functional object"/ 
-- a literally defined function expression (FE). Python has `def`s and 
`lambda`s, Ruby has `def`s, `lambda`s, `proc`s, blocks and other, Erlang 
- casual functions and `fun`s.

JS is better: (1) all functions (FE, (N)FE) are defined syntactically 
the same, (2) all are closures, (3) all are higher-order functions.

So it may be good to keep it the same, but then casual FDs should be 
defined as:

fun foo() {
   ...
}

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

But I guess you want to keep "function" keyword to defined casual FD (or 
"lambda" I've heard). If simple functions will be named as "lambda"s, it 
can also be used in "funargs":

lambda foo() { -- not bad
   ...
}

[1, 2, 3].map(lambda(x) { x * x}); -- also nice

> Perhaps the strawman page for shorter function syntax should list 
> reasons for rejecting other syntax options. I would be happy to 
> document the reasons against fn, fun, f and \, but I can't seem to 
> remember my username and password (I'm not even sure if I have an 
> account). Who can help with wiki access issues?
>

Yeah, that's interesting, I'll follow. I guess you'll describe also how 
bad is "function" keyword _now_ (and not because it's long, I mean that 
"problems" with parser, etc).

> Regards,
> Maciej
>
> [1] http://en.wikipedia.org/wiki/Blocks_(C_language_extension) 
> <http://en.wikipedia.org/wiki/Blocks_%28C_language_extension%29>
>
>
> _______________________________________________
> 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/20100726/f4f78580/attachment-0001.html>


More information about the es-discuss mailing list