Pattern Matching Champions
2024-02-15
plaintext logs
prev next
source on github
17:37
<rbuckton>
During the last plenary session, Shu expressed some concern about the perf cost of iterator destructuring for extractors. I know this is a known concern we've discussed before, which is why we've potentially considered using index/length instead.
danielrosenwasser pointed out to me that in https://peps.python.org/pep-0622/#custom-matching-protocol, Python decided against full-blown custom matchers in favor of a far more limited approach using __match_args__, where something like case Point(1, 2) only tests whether the subject is an instance of Point, and then reads Point.__match_args__ which returns an array containing ordered keys like ["x", "y"], which in turn is used to extract the named properties of the subject to match for those positions.
I admit, I'm not a fan of adopting that approach as it severely limits the value proposition for extractors, but there is something to be said for the possible performance implications. I'm curious what everyone else's thoughts are on this, though.
17:51
<rbuckton>

The other approach discussed briefly in plenary was C#'s Deconstruct, which allows for some custom logic but leverages C#'s out parameters for ordered destructuring:

void Deconstruct(out int x, out int y) {
  x = this.x;
  y = this.y;
}

I have been toying with a ref proposal for a few years that is similar to out (C# also has ref, and the only real difference between ref and out in C# is that an out must be assigned to before a normal return from the function body).

17:54
<Jack Works>
I don't like the python approach
17:55
<Jack Works>
C# approach requires a static type system so don't work for JavaScript
17:56
<Jack Works>
I don't think using iterator is a problem, because react is using it a lot, the engine has to optimize it anyway.
17:58
<rbuckton>
I don't think using iterator is a problem, because react is using it a lot, the engine has to optimize it anyway.
React is not fast, and the engine does not currently optimize it away. In a very limited benchmark, we found const { 0: foo, 1: setFoo } = useState(); is about 20% faster than const [foo, setFoo] = useState() in V8.
18:00
<Jack Works>
yes, I understand. they should do that optimization. not because pattern matching, but react.
18:04
<Jack Works>
but btw if we use index + length, I'm ok for that
18:05
<Jack Works>
It's just a little bit classic, not fit es6 style, but the functionality is good.
18:06
<rbuckton>
ideally, V8 could find ways to improve array->array destructuring, but I don't know how likely that is.
18:08
<Jack Works>
ideally, V8 could find ways to improve array->array destructuring, but I don't know how likely that is.
if Array@iterator, ArrayIterator.next and some other stuff is unmodified and the subject is a real array imo
18:50
<ljharb>
How often is pattern matching going to be in a hot path anyways, and when will it make use of the iterator protocol more likely?
18:54
<mgaudet>
I don't think using iterator is a problem, because react is using it a lot, the engine has to optimize it anyway.
Just going to chime in here and say: No. We will work on react like patterns, but I would very much not like to see this form of argumentation used.
18:56
<mgaudet>
A huge challenge with the iterator protocol is how much of it is observable-if-you-care-to-look, which means engine complexity when trying to boil this away. I would strongly encourage the growth of pattern matching proposal to consider the cost of things without resorting to "engines are magic and can make this go away".
18:58
<mgaudet>
I do worry that pattern matching ends upon the hot path a lot if people think of is as ===-but-better.
18:59
<ljharb>
that's fair
19:00
<ljharb>
i'm not a fan of the iterator protocol, but sometimes it's unavoidable. could we do something like the inverse of array.from? iow, if it's an array, arraylike it, otherwise if iterable, iterate it? that would optimize the most common case
20:00
<rbuckton>
if Array@iterator, ArrayIterator.next and some other stuff is unmodified and the subject is a real array imo
I didn't mean whether it was feasible, just that I cannot make a statement about any implementation's likelihood to implement such an optimization in the near term since they haven't already optimized this given the prevalence of React.
20:09
<mgaudet>
i'm not a fan of the iterator protocol, but sometimes it's unavoidable. could we do something like the inverse of array.from? iow, if it's an array, arraylike it, otherwise if iterable, iterate it? that would optimize the most common case
Possibly!
20:54
<TabAtkins>
I'm definitely okay with the simple "just depend on Array-like" if that's a blocker. Allowing iterators in the way ljharb described would be nice, because any place that takes an Array should take an iterator or else it's a weird wart, tho.
20:54
<TabAtkins>
We definitely expect the pattern to be return [foo, bar, baz] in custom matchers, so preferring Arrays, or even mandating them, would be okay in my book.
21:04
<rbuckton>
Would we expect to expand that to tuples as well?
21:44
<ljharb>
i mean those aren't ever likely to happen at this point, but yes, ofc
21:59
<TabAtkins>
yup
22:27
<TabAtkins>
the next meeting happens to fall on President's Day. who all is available to meet? i'd like to have the meeting if enough of us can do it - otherwise the next one's not til march 4th, and i'd really like to be able to present in april
Unfortunately I'm on vacation next week. :((((( (I leave tomorrow, and am not back until next Friday.) But I'm available on the 26th, and the next several Mondays after that. (March 25th is the first Monday I'm unavailable, as I'll be on vacation again.)
22:28
<TabAtkins>
But please, if next week is all that's workable in the near future, go for it. I'm pretty comfortable with the possible routes we've discussed on the open issues, and trust y'all to decide well.
22:28
<ljharb>
ok, then so far it's myself and mark who've explicitly said they can make it; if there's more then we can still meet, otherwise we can cancel