On 2015/12/04 14:35:32, caitp wrote:
On 2015/12/04 14:34:43, caitp wrote:
> On 2015/12/04 14:32:33, rossberg wrote:
> > On 2015/12/04 14:26:09, caitp wrote:
> > > On 2015/12/04 14:24:21, rossberg wrote:
> > > > The main thing I'm confused about is why we need the rewriting
queue.
What
> > > > prevents you from invoking the rewriting right at the time where
you
> > currently
> > > > just queue it up?
> > >
> > > The main thing is the ambiguity `({ x } = { x: 1 }) => x` << where
the
> meaning
> > > changes depending on whether `=>` is found or not. Binding patterns
are
> > > rewritten differently, so by necessity the rewriting is deferred
until
it's
> > > known for sure what is being rewritten
> >
> > But is anything ever removed from this queue without being rewritten?
I
can't
> > find that happening anywhere, so isn't it always performed
unconditionally
> > anyway, just delayed?
>
> Hmm, that's a good point, right now there might be some redundant
rewriting
> happening. I'm not sure it should be removed from the queue because it
can't
be
> easily, but it can be marked as rewritten to prevent redundant rewriting
--- but, just to be clear, that redundant rewriting doesn't mean that it's
able
to eagerly rewrite, it just means that the redundant rewriting is sort of
discarded, because the RewritableAssignmentExpression itself is discarded
I see. The deeper reason I'm asking is because Niko is now implementing the
rewriting for array literals with spread, which has a similar problem. The
way I
thought this would work is that we introduce something dual to the pattern
rewriter, i.e., an expression visitor that is invoked when an ambiguous
cover-expression/pattern is resolved to be an expression. That would then
walk
and rewrite the necessary expressions inside. (In most cases that would be a
no-op, so it's probably worth introducing a bit in the expression
classifier to
indicate the necessity for rewriting.)
You already have that kind of visitor, it seems, so I wonder why it isn't
possible to invoke it directly at the resolution points.
https://codereview.chromium.org/1309813007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
