08:31 | <Michael Ficarra> | A Coq Mechanization of JavaScript Regular Expression Semantics: https://dl.acm.org/doi/10.1145/3674666 |
13:58 | <jmdyck> | In 6.1, they acknowledge the distinction between main-body and annex B regexes, but don't explicitly say which they're mechanizing (as far as I could see). I'm pretty sure it's just main-body. |
20:10 | <nicolo-ribaudo> | Do the two modes have different features, or just different parsing rules? |
20:10 | <nicolo-ribaudo> |
|
20:42 | <jmdyck> | It's mostly syntax, but it isn't just syntax, some of the pseudocode is different too, so it makes a difference (to the resulting mechanization) which you pick. |
20:43 | <Richard Gibson> | Do the two modes have different features, or just different parsing rules? \c⦠in various possible locations gets really intricate |
20:44 | <jmdyck> | For research purposes, it makes sense for them to stick to the main-body, but I think it's at least worth saying so. |
20:51 | <snek> | i experimented a bit with an nfa vm for engine262 for verifying optimizations, cool to see this approach as well |
22:58 | <bakkot> | I kind of want to propose a Math.argmax(it, fn) which is like (it, fn) => Iterator.from(it).reduce((a, b) => f(a) > f(b) ? a : b) , but apparently Python's (rather numpy's) argmax gives you the index of the maximum item rather actually taking a function. |
22:59 | <bakkot> | possible alternatives:
|
23:00 | <bakkot> | also, I want to suggest that both this and a hypothetical sortBy would allow the function to return any of { number, bigint, string }, and do the natural comparison within each type, but throw if the function ever returns two different types |