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 < [email protected]> wrote: > On 4 November 2014 12:53, Dmitry Lomov <[email protected]> wrote: > > On Tue, Nov 4, 2014 at 12:25 PM, Dmitry Lomov <[email protected]> > wrote: > >> On Tue, Nov 4, 2014 at 11:56 AM, 'Andreas Rossberg' via v8-users > >> <[email protected]> wrote: > >>> > >>> On 4 November 2014 10:16, Dmitry Lomov <[email protected]> wrote: > >>> > On Tue, Nov 4, 2014 at 8:43 AM, 'Andreas Rossberg' via v8-users > >>> > <[email protected]> wrote: > >>> >> > >>> >> On 3 November 2014 16:58, Andreas Rossberg <[email protected]> > >>> >> wrote: > >>> >> > On 3 November 2014 16:47, Caitlin Potter <[email protected]> > >>> >> > 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 > >>> [email protected] > >>> 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 [email protected]. > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> > > > > -- > > -- > > v8-users mailing list > > [email protected] > > 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 [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > -- > v8-users mailing list > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
