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