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. http://jashkenas.github.com/coffee-script/#switch 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.
Dmitry.
On Fri, Jul 23, 2010 at 10:08 AM, Trans <transf...@gmail.com
<mailto:transf...@gmail.com>> wrote:
Hi--
I was reading about the proposed shorter function syntax on the wiki
and want to comment on it.
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
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@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
--
Bryan
http://bryan-kyle.blogspot.com
@bryan_kyle
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
