There is a concept of "expressiveness" in programming languages that has to do
with the notion of whether a feature is "just sugar." A lightweight feature is
one that can be described as a simple, local rewrite into some other feature.
For example, the proposed method shorthand syntax:
{ f(x) { return x + 1 } }
can easily be translated to
{ f: function(x) { return x + 1 } }
By "local rewrite" I mean you can replace the AST node MethodInit(name, args,
body) into an equivalent node PropertyInit(name, FunctionLiteral(args, body)))
without modifying name, args, or body, and the program will behave identically.
Intuitively, sugar doesn't increase the expressiveness of a language; it just
makes for nice little syntactic abstractions for common patterns. This doesn't
really change the *power* of the language because there's nothing you can't do
with the new feature that you couldn't already do with only minor revisions to
the code. Conversely, a feature that *can't* be implemented exclusively with
local rewrites is one that can potentially replace massive amounts of
boilerplate. This is a feature that can fundamentally increase the
expressiveness of the language.
CoffeeScript is, by design, a language that is designed to have the same
expressiveness as JavaScript -- all its features are defined as syntactic
sugar. Harmony is, by design, a language that is designed to have *more*
expressiveness than ES5 -- it contains some features that can't be defined as
syntactic sugar (in addition to some that can).
But there are costs to adding expressiveness, such as the need to adapt tools
like debuggers, as you mention, and the risk of features that are subject to
abuse or unwieldy to program with. That's why we have been very conservative
about only introducing a few such features, using concepts that are
well-studied from other languages, and even then limiting their expressiveness.
For example, generators are strictly less expressive than full coroutines or
continuations. How so? You can expressive the former as sugar for the latter,
but not vice versa.
Dave
On Oct 11, 2011, at 8:00 PM, John J Barton wrote:
>
>
> On Tue, Oct 11, 2011 at 6:17 PM, David Herman <dher...@mozilla.com> wrote:
> > Traceur is very good! I'd just like to have something that compiles to ES5
> > without intermediate libraries, the way CoffeeScript works, so that it's
> > easier to debug and use in NodeJS.
>
> You aren't going to be able to match CoffeeScript's readability for many
> features, especially generators, private names, and proxies. Those require
> deep, whole-program compilation strategies.
>
> I'm unclear, but are you saying: some features translate directly to simple
> JS but some features are more pervasive so their translation will not be as
> readable? So we need to develop new strategies for debugging these features?
> Or something else?
>
> jjb
>
>
>
> Dave
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
