LGTM to implement non-tagged template literals, tagged template literals
pend spec issue resolution.
On Tue, Nov 4, 2014 at 1:33 PM, 'Andreas Rossberg' via v8-users
v8-users@googlegroups.com wrote:
On 4 November 2014 12:53, Dmitry Lomov dslo...@chromium.org wrote:
On Tue, Nov 4, 2014 at 12:25 PM, Dmitry Lomov dslo...@chromium.org
wrote:
On Tue, Nov 4, 2014 at 11:56 AM, 'Andreas Rossberg' via v8-users
v8-users@googlegroups.com wrote:
On 4 November 2014 10:16, Dmitry Lomov dslo...@chromium.org wrote:
On Tue, Nov 4, 2014 at 8:43 AM, 'Andreas Rossberg' via v8-users
v8-users@googlegroups.com wrote:
On 3 November 2014 16:58, Andreas Rossberg rossb...@google.com
wrote:
On 3 November 2014 16:47, Caitlin Potter caitpotte...@gmail.com
wrote:
It looks like there is machinery in `Scope` for storing internal
variables.
Could we not grant each tagged template a custom ID, in order for
it to
look
up the appropriate callSiteObj in scope, and store a new internal
value
there if one does not already exist?
Sounds good to me. That way, we can desugar it in the parser,
which
is
always best.
On re-reading the spec, that doesn't work. A local variable would
only
cache the callSite object per surrounding function invocation, not
globally. The SharedFunctionInfo doesn't work either, because of
code
caching/sharing. We really need to associate the object with the
script identity, but I don't think we have an easy way of doing so.
Correct, that is the main issue here (spec is very unhelpful,
associating
call site to source code - what does it even mean?)
It also indexes them by productions, which is even more meaningless
(I already filed a bug about the misuse of the notion of production
all throughout the spec, but I doubt it will be fixed).
The correct cache seems to be something along the lines of
(native context, script source, postion) = call site
CallSites are (global) context specific of course, that's why we have
native
context on lhs of this relation.
My suggestion would be hanging map of [(hash(script source),
position)
=
call side] off native context.
That's not good enough -- there may be multiple equal scripts executed
within the same realm, especially using eval. They still need to map
to separate call site objects.
I do not believe they should map to separate call sites.
The spec says associated with the source code which does not mean
anything and callsites are frozen so no harm can happen.
As discussed off-line, that's not my interpretation of the spec, but I
filed a bug to get clarification:
https://bugs.ecmascript.org/show_bug.cgi?id=3305
/Andreas
(caching in global context would also work of course but will require
some
tracking from the parser at least - not sure what's best yet)
That's why I suggested something per
_global_ context (which is per script). A mapping like
(global context, script source, position) = call site
would work, presuming we create a global context whenever a script
contains a template literal somewhere (even if the context is
otherwise empty).
I haven't thought through all the implications though (this map has
to
be
cleared some time etc)
Why would it need clearing? It won't be large anyway, and it seems
fine to keep it alive with the associated realm.
One possibility would be to store it as an internal variable in the
global lexical scope of the respective script. But then we'd need
the
preparser to collect respective data about template literals
appearing
in lazily parsed functions, so that we can reserve those slots when
compiling a script (or perhaps just one accumulative slot, pointing
to
a cache object).
/Andreas
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google
Groups
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to v8-users+unsubscr...@googlegroups.com.
For more options,
