> Domenic Denicola <mailto:domenic at domenicdenicola.com>
> September 6, 2013 9:13 AM
> From: Brendan Eich [brendan at mozilla.com]
>
>
> Really? The Firefox and Chrome debuggers, from what I can see, always 
> hide implementation stack frames from us.

This is not about "implementation stack frames". The frame or frames 
would be for your code written in the comprehension expression.

> Are you referring to the C++ debugger you'd use while developing those 
> engines?

We are probably in the weeds, but only slightly. The main thing is the 
spec does not "desugar", but if it did, desugaring to (potentially 
nested) closures would need to be specified instead of what's drafted 
now: generator function with let blocks.

Debuggers can't hide everything, and should not. It's awesome to 
black-box at every level of abstraction, Firefox's devtools support this 
-- it wins for users, never mind built-ins. But let's get back to the 
spec issue.

/be

Domenic Denicola <mailto:domenic at domenicdenicola.com> September 6, 2013 9:13 AM

> Really? The Firefox and Chrome debuggers, from what I can see, always 
> hide implementation stack frames from us.

This is not about "implementation stack frames". The frame or frames 
would be for your code written in the comprehension expression.

> Are you referring to the C++ debugger you'd use while developing those 
> engines?

We are probably in the weeds, but only slightly. The main thing is the 
spec does not "desugar", but if it did, desugaring to (potentially 
nested) closures would need to be specified instead of what's drafted 
now: generator function with let blocks.

Debuggers can't hide everything, and should not. It's awesome to 
black-box at every level of abstraction, Firefox's devtools support this 
-- it wins for users, never mind built-ins. But let's get back to the 
spec issue.