Block lambda is cool, its syntax isn't
claus.reinke at talk21.com
Sat Jan 21 02:09:42 PST 2012
>>> I think "use fn;" (real pragma syntax), with the low-precedence
>>> assignment-expression fn (params) assign-expr production, wins. What do
>>> you think?
>> Having fn would be sweet. For many kinds of pragmas, it would be great if
>> one could configure these per project (or per directory). Then one could
>> put legacy code in one directory and ES6 code in another. And the weight
>> of the pragmas would be negligible. Not sure how to do this, though;
>> reminds me very loosely of CSS (centralized management of style).
> You make a good point: "use fn;" may be too much to require in every
> <script> element content.
>From the Haskell experience again: there, one can have language
- as pragmas in source code 
- as options in package descriptor files 
The former is better for source readability, and for being specific
about which files depend on which extensions. The latter is better
for avoiding repetition if every source in a package uses the same
set of options, and for package readability (making package
feature dependencies obvious without having to scan source files).
In-source pragmas override package-wide options.
One thing that Haskell doesn't have, which I have often wanted,
is the ability to define extension groups on a per-project basis:
if I always use the same sets of extensions (eg, yield and block
scoping, or modules and classes, or ..), then it would be nice
to define pragma groups in the package file, and just refer to
the group pragma in the source files. That way, use of language
features would be explicit in the source, but without repetitive
details. However, this is less of an issue in JS than in Haskell
(the latter has far more language extensions, with a very
conservative base standard, while all ES extensions currently
under discussion will be grouped in ES6).
 "extensions: identifier list"
A list of Haskell extensions used by every module.
Extension names are the constructors of the Extension type.
More information about the es-discuss