Block lambda is cool, its syntax isn't

Axel Rauschmayer axel at
Sat Jan 21 03:31:36 PST 2012

Great stuff. I’m equally intrigued by the `use fn` pragma: It allows one to selectively break compatibility.

Caveat: This kind of pragma introduces a lot of new complexity.

Pragmas would indeed become less burdensome if one could configure them on a per-project basis. It corresponds to Eclipse setting different Java versions per source directory. Ideas (not sure that they are worth the added complexity, but wanted to mention them):

- Meta-tag points to file that configures pragmas based on paths
- Custom, user-defined meta-pragmas that group several pragmas
- A pragma that points to a file with several pragmas

On Jan 21, 2012, at 11:09 , Claus Reinke wrote:

> From the Haskell experience again: there, one can have language
> feature options
> - as pragmas in source code [1]
> - as options in package descriptor files [2]
> 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).
> Claus
> [1]
> [2] "extensions: identifier list"
>   A list of Haskell extensions used by every module.
>   Extension names are the constructors of the Extension type.

Dr. Axel Rauschmayer
axel at


More information about the es-discuss mailing list