And to close the loop: rev37 makes clear that ResolveExport() will follow
re-exported import bindings to discover the module in which they
originated. This makes all the assertions correct. In my example, it means
that the CreateImportBinding call in 'a' is:
CreateImportBinding(x, 'c', x)
Thanks
Tim Yung and I have hacked on a reference implementation for the
Existential Operator using esprima-fb and jstransform: a?.b
Example:
`a?.b` = `(a == null ? void 0 : a.b)`
`a?.b.c` = `(a == null ? void 0 : a.b.c)`
This must also make sure that `a` only gets evaluated a single time.
Based on
If we can come to an agreement on the existential operator for member
expressions, we would also be setting a precedent for other features
of the same family. For example, existential call expressions: `fn?()`
which would conditionally invoke `fn`.
In the meeting notes you linked to,
I guess all built-in iterators return themselves for `Symbol.iterator`
protocol. So they are all singletons. I described in detail where
confusion/substitution of concepts happens in that analysis in the recent
two comments.
Dmitry
On Mon, Apr 6, 2015 at 1:07 PM, joe joe...@gmail.com wrote:
Regardless of what the spec says, you cannot avoid singleton iterators in
real-world code. In my opinion, the spec should refrain from specifying
when object creation happens within the iteration protocol, wait for the
relevant code and contract patterns to develop and then include something
in
Wouldn't option 1 provide the transitivity you're discussing? If `a?.b.c`
calls `(void 0).c` then `(a?.b).c` and `a?.b.c` would be identical, and
both throw a TypeError.
From my reading, it seems like option 2 is the one that does not provide
transitivity, and tbh would surprise me greatly in the
I hacked together something similar myself. IIRC, this particular
transformation has issues with nested operators (e.g. a.b?.c.d?.e.f?.h).
Of course that's an implementation detail, but the problem (if I'm
remembering it right) is that people couldn't figure out what the
implementation
By the way, I don't remember having grammar issues (I use a LALR
compiler-compiler). Looking at my code, it looked like I handled it in the
tokenizer stage; I added a COND_DOT token:
COND_DOT : \?\.
COND_DOT then became simply another binary operator in the Expression
production.
However, this
Christoph Pojer wrote:
Tim Yung and I have hacked on a reference implementation for the
Existential Operator using esprima-fb and jstransform: a?.b
Example:
`a?.b` = `(a == null ? void 0 : a.b)`
`a?.b.c` = `(a == null ? void 0 : a.b.c)`
This must also make sure that `a` only gets
joe wrote:
By the way, I don't remember having grammar issues (I use a LALR
compiler-compiler). Looking at my code, it looked like I handled it
in the tokenizer stage; I added a COND_DOT token:
COND_DOT : \?\.
Did you keep backward compatibility? `x?.1:y` must continue to work.
/be
Yeah, and it would line up with cover grammar needed for
refutable-by-default patterns.
/be
Matthew Robb wrote:
On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Did you keep backward compatibility? `x?.1:y` must continue to work.
On Apr 6, 2015, at 2:23 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
I guess all built-in iterators return themselves for `Symbol.iterator`
protocol. So they are all singletons. I described in detail where
confusion/substitution of concepts happens in that analysis in the
Implement it; user-test it; auto-check the grammar for ambiguity and
other problems.
/be
Christoph Pojer wrote:
So I take it most would prefer this as a prefix operator. What would
be the next steps involved to iterate on this idea?
On Mon, Apr 6, 2015 at 3:35 PM, Brendan
Wouldn't `.?` as an infix operator be unambiguous, compared to `?.`? There's no
place other than decimal literals where this would be legal today, and decimal
literals already require either parenthesis or an extra dot to perform a
property access in any event. With that lexeme, `x.?1:y` would
Axel Rauschmayer wrote:
There are two different aspects:
1. If you get an iterable, it sometimes matters whether iteration
restarts when you ask the iterable for an iterator.
Rather, if you have an object o and o[Symbol.iterator]() === o then you
have an iterator.
2. Self-iterability is
On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich bren...@mozilla.org wrote:
Did you keep backward compatibility? `x?.1:y` must continue to work.
This is why I suggested a leading operator (`?a.?b()`) because it seems
like it would have the least potential for conflict with existing valid
syntax
Exactly, that's what I tried to explain. Since in one case it considers
just an iterable (an array), and in other case -- an iterator (which is by
coincidence is also an iterable). But an array's iterator is an iterable
as well, and also always returns itself for iterator protocol.
Yeah, the
So I take it most would prefer this as a prefix operator. What would
be the next steps involved to iterate on this idea?
On Mon, Apr 6, 2015 at 3:35 PM, Brendan Eich bren...@mozilla.org wrote:
Yeah, and it would line up with cover grammar needed for
refutable-by-default patterns.
/be
There are two different aspects:
1. If you get an iterable, it sometimes matters whether iteration restarts when
you ask the iterable for an iterator.
2. Self-iterability is how iterators turn themselves into iterables so that
constructs that work with iterables can be used. It also enables
19 matches
Mail list logo
