[Webkit-unassigned] [Bug 74718] Remove the `value' argument to op_push_new_scope

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=74718





--- Comment #9 from Andy Wingo <wingo at igalia.com>  2011-12-21 14:24:05 PST ---
(In reply to comment #7)
> Andy, I'm really worried that you'll have to redo most of this code once you start considering performance issues -- eager vs lazy tear-off, optimizing out uncaptured lets, merging captured lets, etc. 

I agree that there are many places where optimizations can be made.  The read barrier will also complicate things.  At some point it might make sense to implement display closures, too.  Still, though, the mechanism is similar enough to `catch' (modulo read barriers) that it does seem like a path to a correct implementation, that can be incrementally turned into a fast implementation in many common cases.

Using JSStaticScope also has the advantage that the code can be tested, even in the absence of ENABLE(HARMONY) or ENABLE(ES6_BLOCK_SCOPE) or whatever.

If you or Gavin gets a chance, I would appreciate a few words on lazy tear-off; it is not something that I ran into yet.

> emitPushBlockScope(...)
> ResolveResult result = resolve(...)
> emitPutScopedVar(result, m_exceptionIdent, exceptionRegister.get())

Will do.

> Then you can get rid of emitInitializeBlockScopedLocal(). As long as you're not optimizing for let yet, you should avoid, as much as possible, building let-specific functionality into the bytecompiler.

Sure.  Note that in ES6, const also has block scope.  And, the catch-bound var and the name of a named function expression also have block scope.  But I like your suggested refactor anyway.

Regards,

Andy

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.