simple shorter function syntax

Dmitry A. Soshnikov dmitry.soshnikov at
Sun Jul 25 05:50:17 PDT 2010

On 23.07.2010 21:24, Bryan Kyle wrote:
> I believe # has the advantage of not being a valid character in an 
> identifier so there won't be any backwards compatibility problems with 
> existing code.

Backward compats are good. But is this a good reason to provide ugly 
syntax constructs into the language? What does this sharp #  mean 
regarding the concept of a "function" in math? No, I'm not conservator, 
but vice-versa, I like innovations (# for functions can quickly become 
familiar and habitual for me). But just think that "fn" or "fun" is more 
human-read and elegantly short at the same time. I don't also see a big 
problem in full "function" keyword because think that every good editor 
should have good autocomplete and snnipets.

> Your suggestions are legal identifiers so it makes the job of the 
> parser harder.  The parser would have to look further ahead to be able 
> to tell the difference between an anonymous function and a call to an 
> existing function.  That isn't to say it's impossible, but simplicity 
> speaks for itself :)

So what? Is it so now with a "funciton" keyword? Why does a parser -- if 
"fn" or "fun" will be keywords (just like currently existing "function") 
should think that it could be a "function call"?

Harmony /anyway/ brings some new syntax constructs, so maybe yet another 
good short innovation -- "fun" (just like in Erlang) or "fn" or even 
"def" (like in Ruby and Python, although I think "fun" is better) is good?

Also I think JS still has some redundant C-syntax garbage. For example, 
that "break" keyword each time in "case" of a "switch" -- for what it is 
there? For what to write several times "case-case-case" if it's possible 
to write it once and separate testing operands with a colon? Moreover, 
this "switch" construct is non-logical in control flow if to place 
"default" not in the end or to forget this "break" garbage. Why on earth 
if I have x = 5 and "case 5:" should I catch also "case 6:" if I forgot 
that useless "break" garbage there? So I like better Ruby's or Coffee's 
way, e.g. Btw, 
there're many good syntax sugars which Harmony can borrow (I know some 
of them are already planned and it's very good, but maybe others too).

Regarding ASI (here also was a talk). It's about client side JS and its 
minification why this can be a problem. "Scary" cases with defining a FE 
(with forgetting semicolon) and call another FE (which is an argument 
for the first one FE) -- are well-known long time and not scary in any 
respect. Generally, explicit semicolon is also a /garbage/ -- new line 
is enough -- with defining all related rules such as what will be with 
"return". ASI mechanism is in many languages and if it's implemented 
well -- it's a good mechanism. I myself use explicit semicolon of course 
-- everywhere. But I think I wouldn't e.g. programming on server-side JS 
where minification into one line is not needed.


> On Fri, Jul 23, 2010 at 10:08 AM, Trans <transfire at 
> <mailto:transfire at>> wrote:
>     Hi--
>     I was reading about the proposed shorter function syntax on the wiki
>     and want to comment on it.
>     I do not see how it is advantageous to using a special symbol, '#'.
>     Taking the example.
>      [0, 1, 2, 3].map( #(x) {x * x} )
>     If the goal is just to be more concise, what is wrong with 'f' as an
>     abbreviation of 'function'?
>      [0, 1, 2, 3].map( f(x) {x * x} )
>     Or 'fn', if it seems a little clearer.
>      [0, 1, 2, 3].map( fn(x) {x * x} )
>     Heck you could even use 'y' as an upside down lambda if you wanted.
>      [0, 1, 2, 3].map( y(x) {x * x} )
>     Any of these seem a much nicer choice than '#', IMHO.
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>
> -- 
> Bryan
> @bryan_kyle
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list