return when desugaring to closures

Brendan Eich brendan at
Thu Aug 21 12:09:31 PDT 2008

On Aug 21, 2008, at 11:45 AM, ihab.awad at wrote:

> On Thu, Aug 21, 2008 at 11:24 AM, Mark S. Miller  
> <erights at> wrote:
>> When it doesn't work, it doesn't work. But when it does work, it's
>> highly worthwhile because it's the closest thing we've got to proper
>> lambda abstraction.
> ... and to *my* mind, the benefit of (defining the semantics as)
> desugaring to something well-understood (be it proper lambda
> abstraction or otherwise) is that the primitives of the language are
> now more amenable to formal -- or even semi-formal -- reasoning.

We have experienced people on the committee who've formalized JS  
subset semantics (Dave Herman, Cormac Flanagan). But the problem I  
keep hammering on is that JS function != Lambda.

>> From our point of view in trying to build secure JavaScript variants,
> what I consider to be a huge breakthrough moment was when MarkM
> realized that we can support existing JavaScript patterns (fondly
> known as "monkey patching") by essentially desugaring one JavaScript
> flavor to another JavaScript flavor, and doing all our security
> reasoning about the second flavor.

This is common practice in the PLT world, right?

> And I'm harping on security -- and support for clear reasoning this
> entails -- because I do believe it is crucial. Our work on the Caja
> group is not unique; there are several JavaScript dialects out there
> all trying to support the ubiquitous sharing of active content. The
> browser's same origin policy no longer works for the brave new world
> of social networks; gadgets; content aggregators; active
> advertisements; and what not.

We've all heard this in committee, somewhat to excess. The solution  
does not, in my opinion, preclude better semantics for new forms.

> "Language as UI" issues are important, yes, but the *most* important
> thing is to be very careful and minimalistic about any new foundations
> that EcmaScript drives into in the ground -- ones that cannot be built
> on top of existing foundations. These have proven to be impossible to
> pull up again.

You don't have to tell me. I've been around this block more than  
anyone now involved, starting in May 1995.

I think you're fighting the last war. There's a risk in not adopting  
what implementations have already proven, beyond what was written  
down (with lots of errata) in 1999.

At best, your position is yin to my yang. I don't think it's a trump  


More information about the Es-discuss mailing list