This may of been beaten to death, so sorry to bring it up again :)
To the extent that design rationales are not recorded on the wiki,
repetition is hard to avoid. There have been just too many variations
in the mailing list archives to make catching up just from there realistic.
Whenever I've thought of shorter function syntax, I think of a shorter
word
for function, nothing else. I honestly don't care what it is, rubyish
like
`def` or `fn` or `func` or your pick. I'm mixed about the goal of
shortening function to something that is uber short. Does it really need
that? No messing with return (although that could be shorter), and then
with block-lambdas, just use that for implicit return, TCP stuff (like w/
array extras or even callbacks).
Of course I'm probably over simplifying as I'm not a language expert but
just my thoughts.
Different people may have different goals, but for some of us,
short functions are not a goal, but merely a pre-requisite.
Possible goals enabled by that include cleaning up callback
nesting without preprocessors or, more generally, defining
your own control structures or, even more generally, defining
your own domain-specific languages (DSLs), embedded in JS.
If you think about that latter goal (defining a language that
is tailor-made for writing and reading the kind of solutions
that your problem domain requires, without having to write
a parser or compiler), then two aspects tend to stand out:
- functions represent variable binding in the embedded DSL,
so they are extremely common, and any syntactic noise
imposed by the host language (JS here) distracts from
the variable binding structure
- inflexibilities in the base language (such as implied bindings,
evaluation order, References as auxiliary constructs, ..)
impose constraints on what is possible to do (or practical
to do) in embedded languages, defeating the advantages
of embedded DSLs
[If you are interested in these kinds of things, try to imagine
defining a set of functions that embeds as JS-like language
core (especially variable bindings, conditionals, loops). In
theory, this should be possible using only functions, function
application, and variables, and very nearly readable with
just a few additional helper functions. In JS practice, once
one has worked around JS limitations, the result tends to
be unreadable, or resembles JQuery/RxJS. Which is why
JS coders tend to give up on the idea of embedding DSLs
and use preprocessors like CoffeeScript or streamline.js]
Now, if we just shorten function/return to fn/ret, we'd still
shadow bindings for this/arguments and targets for return
whenever we wrap some code in a function (which some
posters here refer to as TCP violations). Not to mention
that fn/ret might be used as variable/function names in
existing code. And so we get from simple intentions to
messy details..
Discussing short functions is about as interesting as discussing
their lexical syntax. Most of us would like to move on, and be
able to build on the results. Unfortunately, the discussions have
shown that the details are tricky to get right in the context of JS
syntax, semantics, and pragmatics (such as anticipated usage or
future language evolution). "unfortunate", because everyone
seems to want some progress, but everyone is wary of moving
in the "wrong" direction.
The committee's concerns and insistence on fully worked out
and validateable proposals stem from experience with just how
easy it is to get things wrong. Fully worked out proposals can
also be prototyped, to get practical experience.
Given that some JS engines have only recently caught up with
ES5, it seems safe to say that if ES6 doesn't promise progress in
embedded DSL support within the next few years, then
pre-processors (or alternative languages) are going to win. ES7
is just too far away.
Just my view,
Claus
PS. implicit return (return block completion value) and
non-local return (return to lexically enclosing function)
are not the same thing.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
