| 01:10 | <rkirsling> | given that Temporal seems almost similar to 402 in size, I think it would be an excellent way to ease into having a multifile 262 |
| 01:25 | <rkirsling> | (I could rewrite that as an issue on the repo, I suppose) |
| 07:42 | <ystartsev> | gibson042: mozilla doesn't have any remaining concerns, as i mentioned earlier |
| 07:43 | <ystartsev> | also, we have objected to stage advancement for proposals that did not have stage appropriate materials present such as spec text |
| 07:43 | <ystartsev> | the deadline represents the point at which I finish my collection and summarization of materials for the spidermonkey team, and we begin the process of review |
| 07:44 | <ystartsev> | If we do not have a chance to review, then we can't approriately evaluate a proposal for stage advancement. for lower stage proposals such as stage 1, a detailed review is not required, we are usually just happy to listen |
| 07:44 | <ystartsev> | however for other stages, review is necessary |
| 07:45 | <ystartsev> | in this case, we were following Intl.segmenter closely, we are aware of what is being advanced, however not all members have been and many likely have a similar process as us |
| 07:45 | <ystartsev> | and for this reason, i raised the importance of the deadline. |
| 07:47 | <ystartsev> | I didn't make the decision of prioritization, that is with the chairs, but i support whatever they will choose, as the schedule is particularily challenging this time |
| 07:55 | <ystartsev> | I imagine this is very frustrating for you, and it is unfortunate since Intl.Segmenter has gone through a long and difficult process to get to where it is. However, this is the second time this year that we are looking a proposal you are trying to advance that can, and arguably should be blocked on process grounds. Submitting a proposal for advancement to stage 3 with only one working day until the committee |
| 07:55 | <ystartsev> | member is far too little notice. Would it be helpful for you to review the process document and agenda structure? I would like to see this situation avoided in the future, since it is disappointing to have to say something like this about a proposal that is otherwise in good state. |
| 08:02 | <ystartsev> | (that is, bar the missing review) |
| 09:50 | <ystartsev> | I may have been a bit too direct here, sorry about that. I am open for continuing the conversation though. |
| 12:06 | <littledan> | I want to second what Mozilla is saying about Intl.Segmenter. I want this proposal to advance, but these things should be put up with more notice so that everyone can review them. |
| 12:17 | <littledan> | I think it's more important to declare the advancement with a repository link ahead of the deadline than to have all the slide presentation ready by then (since, ultimately, the advancement is of the contents of the repository) |
| 14:53 | <gibson042> | I'm not disputing the above. The agenda matters, and I own my mistake in adding to it late, and that on its own is grounds for blocking advancement. But Intl.Segmenter was not the only or even the last entry to be added late, and that's even more true for the supporting materials requirement (which includes the slides, but more importantly also includes significant work in proposal repositories between the deadline and the m |
| 14:54 | <rkirsling> | bradleymeck: hmm... it's always smalltalk... :( |
| 14:54 | <gibson042> | As for how to ensure sufficient review time in the future (which I agree is the right perspective), I appreciate upcoming-meeting reminders but would *never* expect someone else to provide them. The root issue for me personally is that the rest of my professional life is very far removed from this space, with a compounding factor in this case of thinking "TC39 in June" when the relevant deadline was well ahead of that. |
| 14:55 | <gibson042> | There is something that would help, though: creating the next meeting's document by the start of the current meeting. This is the time when I'm most likely to be thinking about TC39-relevant content, and it would be really great to add agenda items in the moment rather than taking a note for future action. |
| 14:57 | <littledan> | that often happens, but I guess we don't have the July meeting agenda yet this time around |
| 15:01 | <ystartsev> | i am not really sure what to respond here. I have protested in the past if something was added to the agenda without the required materials, late. and it is clearly outlined in our agenda document that this is a likely outcome |
| 15:01 | <gibson042> | and to be clear, any frustration I feel is self-directed. I had hoped to move JSON.parse source text access forward, but didn't have time to work on it. I was able to Intl.Segmenter only because it was ready to go from before. |
| 15:02 | <gibson042> | I do not have ill feelings towards anyone about this, and ystartsev in particular has been a consistent voice of reason and fairness |
| 15:03 | <ystartsev> | gibson042: i am looking forward to giving this the green light very soon. i think the spec looks good |
| 15:05 | <bterlson> | leobalter: ready in 3 minutes? |
| 15:05 | <keith_miller> | jorendorff: Why have only one function for all iterator helpers? Seem bad for profiling |
| 15:05 | <leobalter> | @bterlson yes, Caridy will present |
| 15:05 | <leobalter> | he's ready too |
| 15:08 | <keith_miller> | jorendorff: Since you'll end up with a megamorphic function for each of the things your iterating |
| 15:08 | <keith_miller> | You really want to know that only one iterable type is going into each loop so you can inline the next functions it. |
| 15:08 | <keith_miller> | into it* |
| 15:09 | <jorendorff> | keith_miller: I don't think it'll end up being bad for profiling. It might be more work to optimize, since it's a new thing |
| 15:09 | <keith_miller> | This is a problem for all the TypedArray share functions too |
| 15:09 | <jorendorff> | the inlining is harder to do |
| 15:09 | <keith_miller> | You'd need to do some very sophisticated optimizations that AFAIK, no engine does |
| 15:10 | <ystartsev> | i have another request for time from the chairs akirose bterlson MylesBorins robpalme -> if there is time, Felienne and i have a 1 min announcement regarding the new research call |
| 15:10 | <keith_miller> | Since you're profiling well see the next call as a virtual call |
| 15:10 | <keith_miller> | will* |
| 15:10 | <keith_miller> | If you see 10 different iterators it's going to be 10 different call targets |
| 15:10 | <bterlson> | ystartsev: literally 1 minute? |
| 15:10 | <jorendorff> | keith_miller: It is up to the implementation to decide whether it's a virtual call or what. It could easily be part of the "hidden class" that is not visible to users |
| 15:11 | <jorendorff> | keith_miller: I say "easily", knowing nothing about how that's implemented in other engines |
| 15:11 | <ystartsev> | for anyone here, Felienne and I are opening out 1:1 research call to everyone, who might want to discuss data gathering and research methods, first one is June 25 at 17:45 CEST |
| 15:11 | <ystartsev> | bterlson: it is exactly that ^ |
| 15:11 | <akirose> | quick PSA for everyone |
| 15:11 | <keith_miller> | jorendorff: You have 10 different hidden objects in coming into map each has a different next function |
| 15:11 | <jorendorff> | keith_miller: but if an implementation wants to make all of these objects distinct types, it certainly can. |
| 15:12 | <keith_miller> | How do you inline those nexts into map without map being inlined into every caller? |
| 15:12 | <jorendorff> | oh, you mean optimizing .map() itself, rather than .next()? |
| 15:12 | <akirose> | any time you have one of those moments where you're like "i need to request a little schedule change in the middle of the meeting and idk which chair to ping" |
| 15:12 | <keith_miller> | jorendorff: yeah |
| 15:12 | <jorendorff> | you have *many* different objects coming into .map(), it's a method on Iterator.prototype |
| 15:12 | <keith_miller> | I want to be able to trivially inline the next call into the map |
| 15:12 | <akirose> | any time you need to send a quick message to the chair group |
| 15:12 | <devsnek> | i just joined, did he say why import() is on realms? |
| 15:12 | <jorendorff> | could be called on anything |
| 15:12 | <akirose> | use `/notice #tc39-chairs your message here` |
| 15:12 | <keith_miller> | but that's exactly why I want it to be one per iterator helper prototype |
| 15:13 | <leobalter> | devsnek: we will have more examples over the import() in Realms and use cases |
| 15:14 | <jorendorff> | keith_miller: I want to make sure I understand. "inlining next into map" doesn't make sense to me because Iterator.prototype.map doesn't call any next method |
| 15:14 | <jorendorff> | But also I think you have a particular implementation in mind that does inlining but then can't specialize on what is inlined, forgive me, I don't know much about that stuff to begin with |
| 15:14 | <devsnek> | keith_miller: the next methods call into differing user code |
| 15:16 | <jorendorff> | keith_miller: but just to be clear, this is a performance problem caused by the extra level of indirection, right? and not a profiling problem exactly |
| 15:16 | <keith_miller> | It can't inline when calls are non-monomorphic because it's almost never profitable to do inlining there |
| 15:16 | <ljharb> | gibson042: i'll create the july agenda today |
| 15:16 | <devsnek> | they should have the same characteristics as optimizing Generator.prototype.next except you know a lot more about the body of the generator |
| 15:16 | <keith_miller> | It's a performance problem because inlining when monomorphic can be VERY profitable |
| 15:16 | <keith_miller> | So over sharing functions can hurt performance |
| 15:17 | <keith_miller> | jorendorff: To clarify this is to share map with Iterator.prototype and AsyncIterator.prototype on some shared prototyp? |
| 15:17 | <keith_miller> | maybe I misunderstood the slides |
| 15:18 | <jorendorff> | keith_miller: yeah, let's start over :) |
| 15:18 | <keith_miller> | haha ok |
| 15:18 | <jorendorff> | keith_miller: so, Iterator.prototype and AsyncIterator.prototype are totally separate prototype chains, we can set aside AsyncIterator |
| 15:18 | <keith_miller> | it's too early for me >.> |
| 15:18 | <jorendorff> | keith_miller: no, you're great, I'm glad you brought it up |
| 15:18 | <jorendorff> | they're different interfaces |
| 15:19 | <jorendorff> | so Iterator.prototype.map is inherently a generic method shared across all (sync) iterators. |
| 15:20 | <jorendorff> | AIUI Array.prototype.map already poses some issues for inlining strategy because the mapFn you pass to it will be different every time; the function call in there is megamorphic, unless you inline .map into its caller |
| 15:20 | <jorendorff> | and then it magically isn't |
| 15:21 | <jorendorff> | Iterator.prototype.map is like that, only much worse, because |
| 15:21 | <keith_miller> | jorendorff: The main difference is that for any given iterator the next will be the same consistently |
| 15:21 | <jorendorff> | 1. it has the same problem with mapFn; |
| 15:21 | <jorendorff> | 2. it *also* is going to be megamorphic in `this` which will be all different kinds of iterator |
| 15:21 | <jorendorff> | each with a different next method, layout etc. |
| 15:21 | <keith_miller> | I mean I can imagine things that change their next but... that seems rare |
| 15:22 | <jorendorff> | no, there are already a dozen next methods in the spec |
| 15:22 | <jorendorff> | many iterator types |
| 15:22 | <jorendorff> | but we're not done yet |
| 15:23 | <jorendorff> | 3. Array.prototype.map() at least gets to do all its work at once. Iterator.prototype.map() has to return an iterator. The JIT doesn't necessarily get to see how/where that iterator is used |
| 15:23 | <keith_miller> | I get that, I'm saying that each prototype that has a next could also have a map. |
| 15:23 | <keith_miller> | That's a bit grosser because user iterators don't have access to a map |
| 15:24 | <keith_miller> | Otherwise users will be better off, for each iterator adding their own map function, since they'll likely get better performance |
| 15:24 | <keith_miller> | i.e. put a new map onto each ArrayIterator.prototype MapIterator.prototype, etc |
| 15:26 | <jorendorff> | there are about 12 iterator helper methods |
| 15:27 | <keith_miller> | FWIW, I've given this advice to people using typed arrays that had perf problems |
| 15:27 | <jorendorff> | makes sense |
| 15:27 | <keith_miller> | IIRC, they got a 2-4x improvement |
| 15:27 | <jorendorff> | just working in pure JS? |
| 15:27 | <keith_miller> | Yeah |
| 15:27 | <keith_miller> | I mean they can also skip a bunch of checks |
| 15:27 | <ljharb> | keith_miller: i mean, should the spec add a .map for each TypedArray type? |
| 15:27 | <ljharb> | if that's inherently more performant? |
| 15:28 | <keith_miller> | ljharb: It used to! |
| 15:28 | <keith_miller> | then ES6 changed it lol |
| 15:28 | <Bakkot> | that one seems like not an obviously bad idea, tbh |
| 15:28 | <ljharb> | i mean like, philosophically imo the current way it's done is better, with a single method |
| 15:28 | <Bakkot> | but the iterator helpers seem more obviously like shared things, to me |
| 15:29 | <ljharb> | but if there's a significant perf improvement from not sharing the methods, and it's not likely to ever be overcome, then we should be encouraging non=-sharing of megamorphic things as a pattern (which, coincidentally, is what the "remove species" proposal will force for subclasses) |
| 15:29 | <devsnek> | an iterator is free to specialize the implementation of something on the prototype |
| 15:30 | <devsnek> | for example if your iterator is over a collection type, the map can walk directly over that instead of indirecting through the collection iterator |
| 15:30 | <keith_miller> | Sorry, 🐈 had a panic attack that I was up but didn't feed them |
| 15:31 | <jorendorff> | no worries |
| 15:31 | <keith_miller> | Yeah, we could move back to pre-ES6 behavior |
| 15:31 | <keith_miller> | I'm not opposed to that |
| 15:31 | <devsnek> | did leo say why import is directly on realms instead of compartments |
| 15:32 | <devsnek> | i got distracted by iterator stuff |
| 15:32 | <keith_miller> | devsnek: The hard part is when is it profitable to decide to do that, which requires profiling, which has costs |
| 15:32 | <devsnek> | keith_miller: oh i meant a human can do that |
| 15:33 | <bradleymeck> | devsnek: it's going to be on a realm which has a root/host provided behavior, compartment would have a more granular/user provided behavior. so both would be having a import mechanism |
| 15:33 | <ystartsev> | does metamorphic mean this? https://en.wikipedia.org/wiki/Inline_caching#Megamorphic_inline_caching |
| 15:33 | <ystartsev> | s\meta\mega |
| 15:33 | <devsnek> | bradleymeck: doesn't a compartment with no hook defer to the host? |
| 15:33 | <devsnek> | ystartsev: yeah |
| 15:34 | <keith_miller> | devsnek: In the engine? That would still be hard because you'd need to teach executables that they can have different ones base on the this value |
| 15:34 | <bradleymeck> | for import, it should defer to its realm |
| 15:34 | <keith_miller> | it's not impossible but it's far far from simple |
| 15:34 | <devsnek> | keith_miller: no i meant like, if you're writing a hashmap class in js, you can bring your own iterator forEach impl |
| 15:34 | <gibson042> | does anyone have a link to the slides that Caridy is presenting? |
| 15:34 | <keith_miller> | Oh, yeah, that's the recommendation I've given to devs when they find these methods hot |
| 15:35 | <keith_miller> | are hot* |
| 15:35 | <leobalter> | gibson042: https://docs.google.com/presentation/d/1TfVtfolisUrxAPflzm8wIhBBv_7ij3KLeqkfpdvpFiQ/edit?ts=5ed5d3e7 |
| 15:35 | <keith_miller> | devsnek: but I'd be good for that to be "free" |
| 15:35 | <gibson042> | thank you |
| 15:35 | <devsnek> | bradleymeck: the realm is the host, cuz the realm can't hook anything |
| 15:36 | <bradleymeck> | realm inside a compartment is hooked |
| 15:36 | <keith_miller> | jorendorff: shu: Does SM/V8 do inlining? |
| 15:36 | <leobalter> | devsnek bradleymeck I can't focus in answering here but if you could bring it to the queue... |
| 15:36 | <keith_miller> | I don't actually know. I assume yes |
| 15:36 | <devsnek> | v8 has inlining |
| 15:37 | <devsnek> | i won't go so far as to say what makes something eligible for it |
| 15:37 | <shu> | keith_miller: in the optimized tier, yes |
| 15:37 | <keith_miller> | devsnek: I mean JSC's heuristic is basically just bytecode size... |
| 15:37 | <shu> | keith_miller: both user code and manually written inlines for recognized builtins |
| 15:37 | <keith_miller> | which is a surprisingly good heuristic |
| 15:38 | <devsnek> | all i know about v8's inlining is that the compiler doesn't account for the scope changing and you have to manually look it up every time |
| 15:38 | <keith_miller> | shu: Oh, you can't parse your torque (name?) bytecode for builtins? |
| 15:38 | <devsnek> | torque doesn't have bytecode |
| 15:38 | <shu> | keith_miller: torque compiles down to masm calls, basically |
| 15:38 | <devsnek> | it compiles to c++ csa |
| 15:39 | <keith_miller> | Ah, I thought it was compiled to bytecode |
| 15:39 | <keith_miller> | my b |
| 15:39 | <ystartsev> | keith_miller: sm has inlining |
| 15:40 | <keith_miller> | Cool so then I'd guess every has some flavor of the issue I'm talking about |
| 15:40 | <jorendorff> | keith_miller: Yes, SM does inlining in the most-optimized tier |
| 15:40 | <keith_miller> | everyone* |
| 15:40 | <shu> | keith_miller: that seems like a reasonable extension to me, of parsing torque, identifying the fast paths, and auto-generating optimized tier specializations as well |
| 15:40 | <keith_miller> | jorendorff: Do you have more than one optimizing tier? I thought it was just one? |
| 15:40 | <shu> | keith_miller: though i'm not on the compiler team and that might not be feasible for other reasons |
| 15:40 | <keith_miller> | fair enough |
| 15:40 | <jorendorff> | keith_miller: just the one |
| 15:41 | <devsnek> | shu: i think its generally more profitable to handle the output of torque in the graph form |
| 15:42 | <keith_miller> | jorendorff Yeah, wasn't sure from the phrasing. Inlining into a template JIT seems less profitable :P |
| 15:44 | <shu> | devsnek: not sure what you mean; if what you're driving at is torque needing a new output format that feeds into the graph builder instead emitting CSA calls, then i agree |
| 15:45 | <devsnek> | shu: does csa not go through the sea of nodes graph |
| 15:46 | <devsnek> | graph reducer |
| 15:50 | <shu> | devsnek: yes but that's pretty low level. my intuition is you need to do some higher-level processing to identify what fast paths make sense to emit for the optimized tier |
| 15:54 | <ystartsev> | sorry, more dumb questions. What does CSA mean? my search turned up Coupled Simulated Annealing |
| 15:54 | <shu> | it's a v8-ism |
| 15:54 | <shu> | CodeStubAssembler |
| 15:54 | <ljharb> | shu: is that you typing? |
| 15:54 | <shu> | a higher-level assembler abstracion |
| 15:54 | <shu> | oops sorryu |
| 15:54 | <ystartsev> | i see, thanks for the clarification |
| 15:54 | <rkirsling> | heh I tried to figure that out from googling too but it's part of the Torque article evidently |
| 15:55 | <rkirsling> | er well linked from there |
| 15:55 | <rkirsling> | (https://v8.dev/blog/csa) |
| 15:55 | <ystartsev> | neat, thanks for the link |
| 15:56 | <devsnek> | the idea of torque is basically to make writing csa less of a pain |
| 15:57 | <rkirsling> | JSC just uses JS itself but with reviewer-enforced stylistic restrictions, hehe |
| 15:57 | <devsnek> | v8 used to do that |
| 16:00 | <jorendorff> | Right, SM does that. Ours is not great; it's kind of JS, but with every one-off hack we need |
| 16:01 | <jorendorff> | Apart from our lack of investment, JS turns out to be a kind of meh language for the purpose of implementing spec algorithms |
| 16:02 | <shu> | my view is SM and V8 have both been bitten by the cons of self-hosting |
| 16:03 | <bradleymeck> | node is also doing some stylistic stuff with robustness :-/ , it is difficult at best and definitely down to human review |
| 16:04 | <devsnek> | that glorious span of time where people hated promises because v8's self-hosted impl was so slow |
| 16:04 | <bradleymeck> | so even runtimes ontop of engines are doing this kind of stuff |
| 16:07 | <michaelficarra> | AFAIK chemists use Celsius |
| 16:07 | <michaelficarra> | which scientific fields primarily use Kelvin? |
| 16:07 | <ystartsev> | maybe physics? |
| 16:07 | <rkirsling> | astrophysics surely |
| 16:07 | <michaelficarra> | I would guess physics? |
| 16:08 | <ljharb> | physics for sure |
| 16:09 | <akirose> | y'all see all the "missing information" tags on these new delegate issues? I'd love to get them wrapped & closed! pls check if you're on there or someone you know is https://github.com/tc39/Admin-and-Business/issues |
| 16:10 | <michaelficarra> | as an American, I can't help but be embarrassed during this presentation |
| 16:11 | <bterlson> | Except for fahrenheit which is a superior scale for non-scientific applications 😀 |
| 16:12 | <rkirsling> | :fry: |
| 16:15 | <shu> | what is the phrase they're saying? |
| 16:15 | <shu> | baby highs? |
| 16:15 | <drousso> | @bterlson +1 omg _thank you_ yes |
| 16:16 | <bradleymeck> | shu: baby heights |
| 16:17 | <shu> | does that... use different units than teenager heights or adult heights? i am not a parent |
| 16:18 | <ljharb> | baby height is "about 4 inches higher than you thought was safe" |
| 16:18 | <Bakkot> | baby heights are inches |
| 16:18 | <Bakkot> | not feet and inches |
| 16:18 | <Bakkot> | so, yes |
| 16:18 | <robpalme> | maybe it's locale specific. in the uk babies are measured in cm |
| 16:18 | <ystartsev> | i suspect this is for temporaldeadzone |
| 16:18 | <ljharb> | oh oops, sorry |
| 16:32 | <littledan> | I'm curious why we're prioritizing Intl.Segmenter when it was a late agenda addition |
| 16:33 | <littledan> | this is pushing other things off the agenda that were added before the agenda deadline |
| 16:34 | <rkirsling> | wow that Array.from second param |
| 16:35 | <michaelficarra> | littledan: we discussed this yesterday, late additions do not mean deprioritised |
| 16:35 | <michaelficarra> | we should still prioritise higher-stage proposals over lower-stage ones |
| 16:36 | <littledan> | sorry, I guess I missed that discussion (and continue to disagree) |
| 16:36 | <michaelficarra> | by "we discussed this yesterday", I mean it was discussed in this channel yesterday |
| 16:36 | <michaelficarra> | I did not mean to imply you were present |
| 16:36 | <littledan> | right, I didn't mean to imply that anyone but me was at fault for missing it |
| 16:37 | <shu> | ystartsev: do you think subclassing removal would benefit from an incubation call? i'm thinking no, since the feedback we want are not from delegates |
| 16:37 | <ystartsev> | i think no |
| 16:37 | <michaelficarra> | littledan: we can have that process discussion at some point, but there's no precedent for changing priority based on when an agenda item was added |
| 16:38 | <ljharb> | the deadline has always been indended only for advancement, since that's the only thing that requires sufficient time to review |
| 16:39 | <littledan> | I'll drop this; it's not productive for me to be complaining, and I hope the presenter understands that this isn't personal (of course I'm a fan of this proposal, and I'm really happy that the presenter has taken it up and is championing it in an improved direction from when I started it) |
| 16:40 | <littledan> | I've reviewed these changes and they all seem like good ideas to me |
| 16:40 | <littledan> | well, except I disagree about the exotic internal slots hazard |
| 16:41 | <michaelficarra> | I wish the committee would form a consistent security model that we can use to inform our designs |
| 16:41 | <michaelficarra> | I feel we are constantly going back and forth on whether the model SES is based on is valid |
| 16:41 | <shu> | michaelficarra: yes, i wish we'd settle as well |
| 16:42 | <drousso> | +1 |
| 16:42 | <shu> | michaelficarra: though of course i am, as a browser, firmly on the invalid side |
| 16:42 | <littledan> | so, the exotic internal slot thing seems new. I've been working on following SES constraints for years, but this is a new idea about restrictions on proposals |
| 16:42 | <littledan> | I don't see why you couldn't have a prototype around something that has an internal slot containing an object |
| 16:43 | <devsnek> | did we move to Promise.any stuff |
| 16:43 | <ljharb> | no but the concern overlaps |
| 16:44 | <devsnek> | promises have internal slots that hold non-primitive data |
| 16:44 | <devsnek> | thenables and whatnot |
| 16:44 | <ljharb> | the problem isn't slots holding objects |
| 16:44 | <ljharb> | it's *revealing* mutable objects, held in slots |
| 16:45 | <ystartsev> | michaelficarra: yeah same. |
| 16:46 | <ljharb> | i think the real issue here is that the design of Proxy didn't account for internal slots "properly" for the security model they have in mind |
| 16:47 | <michaelficarra> | sounds about right ljharb |
| 16:48 | <ljharb> | sorry |
| 16:49 | <ljharb> | every single JS type besides Error and Array has prototype methods that check internal slots and thus throw on proxies |
| 16:49 | <ljharb> | that slots make proxies throw is irrelevant here |
| 16:50 | <ljharb> | (specifically, things with exotic objects are defined in the spec to mean "has exotic internal methods" which has nothing to do with slots) |
| 16:51 | <sffc> | mpcsh, maybe try reloading the doc? There is a lot of activity, and maybe you have lag |
| 16:51 | <ljharb> | (objects are also data; "primitives" is the term that we should be using here) |
| 16:52 | <mpcsh> | sffc: good call |
| 16:54 | <jorendorff> | https://tc39.es/ecma262/#sec-get-%typedarray%.prototype.buffer |
| 16:55 | <rkirsling> | is there any precedent for "getting back to the Intl class instance"? |
| 16:55 | <rkirsling> | seems super random |
| 16:55 | <jorendorff> | ^ that seems to be a getter that returns an object out of an internal slot |
| 16:56 | <ljharb> | jorendorff: ohhhh snap |
| 16:56 | <shu> | lol what is going on right now |
| 16:56 | <shu> | how are function closures not reified |
| 16:56 | <shu> | ??? |
| 16:56 | <ljharb> | i can clarify but i don't think this discussion is useful right now |
| 16:56 | <devsnek> | they're using the word closure differently |
| 16:57 | <devsnek> | waldemar is referring to the function as a closure |
| 16:57 | <michaelficarra> | I don't think there's an ecmascript value that we call a "closure" in the spec |
| 16:57 | <shu> | i don't think there are different meanings of "closure", there is a single meaning of closure |
| 16:57 | <devsnek> | and someone else is using the term closure to refer to the scope |
| 16:57 | <devsnek> | not the function |
| 16:57 | <jorendorff> | ljharb is right, this conversation is *terrible* |
| 16:58 | <michaelficarra> | ^ |
| 16:59 | <michaelficarra> | really, I blame this committee for not having a consistent security model that we could be reasoning about right now |
| 17:00 | <sffc> | +1 shu, let's not hypothesize about SES without Mark Miller here |
| 17:01 | <bterlson> | You want to do the opposite of table it. It's on the table right now; we're discussing it. |
| 17:01 | <NilSet> | seems to me like if the membrane pattern is fragile to changes in the spec like this, it SHOULD in fact be actually part of the spec |
| 17:01 | <rkirsling> | bterlson: boooo |
| 17:02 | <shu> | have i been using "tabling" wrong my entire life?? |
| 17:02 | <bterlson> | sorry no |
| 17:02 | <ljharb> | NilSet: that, or, we should have consensus not to support that pattern. the problem is that consensus for either one is likely not possible. |
| 17:02 | <rkirsling> | shu: no you're 100% correct for US english |
| 17:02 | <bterlson> | US vs British english distinction |
| 17:02 | <shu> | for real? |
| 17:02 | <shu> | it means the opposite in british english? |
| 17:02 | <rkirsling> | yeah it's literally the opposite |
| 17:02 | <rkirsling> | it's horrible |
| 17:02 | <bterlson> | IMO the meaning of "to table" is one of the few things British English gets right. We already have ways to say "defer" |
| 17:03 | <ljharb> | bollocks |
| 17:03 | <drousso> | wow |
| 17:03 | <drousso> | 🤯🤯🤯 |
| 17:03 | <ljharb> | but i'll take my blown mind about UK english's meaning of "table" to tdz |
| 17:03 | <ryzokuken> | https://english.stackexchange.com/questions/16285/what-is-the-meaning-of-the-expression-we-can-table-this |
| 17:03 | <sffc> | For a US-based meeting let's use the US definition of "table" :) |
| 17:03 | <rkirsling> | bterlson: we also have ways to say "schedule" though |
| 17:04 | <bterlson> | table is to bring up for discussion immediately |
| 17:04 | <bterlson> | it's also a good metaphor. You table a proposal. You can table supporting documents. |
| 17:06 | <NilSet> | so table is a contronym? |
| 17:06 | <NilSet> | like chuffed? |
| 17:09 | <ljharb> | NilSet: join #temporaldeadzone, i have questions |
| 17:29 | <devsnek> | is frank tang on irc |
| 17:59 | <robpalme> | we are restarting in 1 minute! |
| 18:13 | <littledan> | devsnek: I don't think so but I can introduce you by email if you want |
| 18:13 | <devsnek> | oh i just wanted to let him know his camera was on during lunch |
| 18:15 | <ljharb> | littledan: fwiw we do have that strawperson solution, it's the spaceship operator |
| 18:16 | <littledan> | ah OK. That would work with Arrays? |
| 18:16 | <littledan> | maybe we should go down the queue? |
| 18:17 | <ljharb> | littledan: yes, it would come with a Symbol.compare protocol, as in the example in the slides, that would be defined on Array.prototype |
| 18:17 | <howdoi> | [false, null, 1, "1"].sort() today would return [ 1, '1', false, null ] |
| 18:19 | <ljharb> | shu: (not to preempt your queue item) but arrays can contain any value, so to compare array contents we need to know how to compare any variable |
| 18:19 | <ljharb> | *any value |
| 18:22 | <michaelficarra> | I agree with Shu that I do not want to spend committee time on the black hole that is generic equality |
| 18:22 | <shu> | it's a bigger hole than just equality |
| 18:23 | <michaelficarra> | that's true, also ordering |
| 18:23 | <rkirsling> | I think shu's summarized opinion was quite well put |
| 18:23 | <shu> | i don't think we should think about partial orders and so forth |
| 18:23 | <michaelficarra> | I don't think we should spend time on either individually or both |
| 18:23 | <shu> | to wit, i don't think it's sensical kinda along the arguments that waldemar put forward |
| 18:24 | <michaelficarra> | does Set equality take into account the insertion order? gross |
| 18:24 | <devsnek> | its observable via -0 |
| 18:24 | <michaelficarra> | it's observable via iteration |
| 18:24 | <ljharb> | michaelficarra: it wouldn't have to |
| 18:24 | <ljharb> | michaelficarra: all the deepEqual libraries on npm do not regard order in Set and Map comparison |
| 18:25 | <ljharb> | (also node's assert) |
| 18:25 | <michaelficarra> | that doesn't mean it's the *one true equality definition* |
| 18:25 | <Bakkot> | if I want it to do I need to overwrite Set.prototype[Symbol.whatever]? |
| 18:25 | <ljharb> | iow the semantics for how to judge values as equal are already largely consistent in the ecosystem |
| 18:25 | <ljharb> | Bakkot: replace it, or shadow it via own or subclass, yes |
| 18:26 | <rbuckton> | I'm interested in exploring equality, relational equality, and structural equality |
| 18:27 | <shu> | rbuckton: what is relational equality? |
| 18:27 | <rbuckton> | relational operators, essentially `Symbol.compare` |
| 18:28 | <rbuckton> | (from the slides) |
| 18:28 | <shu> | what is the equality part of "relational equality"? |
| 18:29 | <rbuckton> | I'm just talking about relational operators like `<`, `<=`, `>`, `>=` |
| 18:29 | <shu> | ah okay |
| 18:30 | <rbuckton> | For example, If we had a `[Symbol.compareTo]` method, we could have `Array.prototype.sort` use that as a fallback before going to comparing the `ToString` of each element. |
| 18:32 | <michaelficarra> | agree with Shu again, even though he jumped queue |
| 18:32 | <shu> | i'm sorry i didn't know there was a queue! |
| 18:32 | <shu> | thought it was empty, should have the tab open |
| 18:32 | <michaelficarra> | there's always a queue |
| 18:33 | <michaelficarra> | :-P |
| 18:33 | <shu> | i heard rob said it was empty |
| 18:33 | <akirose> | it was |
| 18:33 | <akirose> | and then it wasn't |
| 18:34 | <michaelficarra> | good point, littledan, public perception of what we've approved is important |
| 18:35 | <shu> | agree |
| 18:35 | <ljharb> | +1 |
| 18:35 | <michaelficarra> | I'm very happy in general with everyone's contributions during this topic. Good job everyone! |
| 18:36 | <rkirsling> | :nod: |
| 18:37 | <littledan> | ftr I think a spaceship operator someday would be awesome, but I agree with Waldemar that it would need to be four-valued |
| 18:37 | <devsnek> | what's the fourth value |
| 18:37 | <devsnek> | no comparison? |
| 18:37 | <littledan> | maybe spaceship could be built on operator overloading, if we do that. It'd be cool if spaceship and other comparison operators kinda agreed |
| 18:38 | <littledan> | devsnek: Yes, uncomparable. Like NaN, but there are other partial orders |
| 18:38 | <rkirsling> | mmm negative indices |
| 18:38 | <ljharb> | negative, postiive, zero, NaN? |
| 18:38 | <devsnek> | +Infinity, -Infinity, 0, null |
| 18:39 | <michaelficarra> | ljharb: may want to look here for some inspiration: https://pursuit.purescript.org/packages/purescript-higher-order/0.2.0/docs/Data.PartialOrd#t:PartialOrd |
| 18:39 | <ljharb> | "just true"? |
| 18:40 | <devsnek> | or https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html |
| 18:40 | <ljharb> | those laws do make sense to me tho; if i wasn't afraid of touching > and < and == i'd expect them all to agree |
| 18:40 | <michaelficarra> | are Arguments exotic objects "indexable"? |
| 18:40 | <ljharb> | yes? |
| 18:41 | <michaelficarra> | so how will they get this method? |
| 18:41 | <devsnek> | i don't see much of a reason to add it |
| 18:41 | <rbuckton> | What I've been thinking about is a set of protocols and APIs around equality: |
| 18:41 | <rbuckton> | - `[@@equals](other)`, `[@@hash]()` - Allows an object itself to define whether it is equal to another object in a generic fashion. Useful for `Map`, `Set`, and cross-compatibility between userland libraries. |
| 18:41 | <rbuckton> | - `[@@compareTo](other)` - Defines a relational comparison on an object itself, returning `-1 | 0 | 1` (similar to this proposal) |
| 18:41 | <rbuckton> | - `[@@structuralEquals](other, equaler)` - Allows an object to define how it should be equated structurally with another object, using the provided `Equaler` (see below) |
| 18:41 | <rbuckton> | - `[@@structuralHash](equaler)` - A version of `@@hash` for structural equality. |
| 18:41 | <rbuckton> | - `[@@structuralCompareTo](other, comparer)` - A version of `@@compareTo` for structural comparisons. |
| 18:41 | <rbuckton> | - `Equaler` - An object with `equals(a, b)` and `hash(a)` methods that can be used to define equality independent of objects. Also useful for `Map` and `Set` when working with keys that do not maintain their own `@@equals`/`@@hash` members. |
| 18:41 | <rbuckton> | - `Comparer` - An object with a `compare(a, b)` method that can be used to define comparability independent of objects. |
| 18:41 | <rbuckton> | - `StructuralEqualer` - An object with `structuralEquals(a, b, equaler)` and `structuralHash(a, equaler)` methods. |
| 18:42 | <rbuckton> | - `StructuralComparer` - An object with `structuralCompare(a, b, comparer)` methods. |
| 18:42 | <rbuckton> | The design is derived from `IEquatable`, `IComparable`, `IStructuralEquatable`, `IStructuralComparable`, `EqualityComparer`, and `Comparer` in C#/.NET. |
| 18:42 | <ljharb> | eesh |
| 18:42 | <devsnek> | but its not like they can't have an own property |
| 18:43 | <michaelficarra> | rbuckton: you don't need to end every proposal with "this design is derived from […] C#/.NET"; we already know |
| 18:43 | <ljharb> | lulz |
| 18:43 | <rbuckton> | michaelficarra: :P |
| 18:44 | <devsnek> | i need to start adding js features to c# |
| 18:44 | <devsnek> | to balance it out |
| 18:44 | <ljharb> | add typeof null |
| 18:44 | <ljharb> | oops this isn't tdz |
| 18:44 | <rkirsling> | michaelficarra: 🔥 |
| 18:45 | <michaelficarra> | rbuckton: 💙 |
| 18:45 | <rbuckton> | ActiveX/COM objects in old IE/Chakra exposed both an indexer and a `item()` method with the same meaning. Probably not a compat issue for Array.prototype... |
| 18:45 | <Bakkot> | I feel like switching null to undefined is going to break stuff |
| 18:45 | <rbuckton> | michaelficarra: not always true though, partial application isn't based on .NET at all :) |
| 18:46 | <jorendorff> | (re: null → undefined) yes ...only if anyone is using .item() to start with |
| 18:47 | <Bakkot> | fair |
| 18:47 | <Bakkot> | i assumed it was common |
| 18:47 | <jorendorff> | maybe? literally no idea |
| 18:47 | <Bakkot> | I guess I'd usually use the indexing syntax though |
| 18:47 | <rkirsling> | I would be surprised if it's a thing |
| 18:47 | <rkirsling> | but the web is a surprising place, so who knows |
| 18:48 | <Bakkot> | michaelficarra I don't see a reason to want that |
| 18:48 | <devsnek> | michaelficarra: own proprety :P |
| 18:49 | <Bakkot> | I don't see a reason for people to have arguments objects in new code at all |
| 18:49 | <jorendorff> | it's funny to have `arr.item(Infinity)` able to hit an expando property |
| 18:49 | <rickbutton> | sometimes you have to make bad choices to level out the good ones Bakkot |
| 18:49 | <haxjs> | I guess if we can had arguments be array, it already be array in ES6? |
| 18:50 | <jorendorff> | it's also funny to have `arr.item(-100)`, where arr.length is 3, able to hit expando properties |
| 18:50 | <jridgewell> | We define `Symbol.iterator` on `arguments` |
| 18:50 | <Bakkot> | haxjs I don't know if we explored having arguments be an array in strict mode. it definitely could not be in sloppy mode because there is the magical behavior of mapped arguments objects |
| 18:50 | <jridgewell> | As an own-data method |
| 18:50 | <leobalter> | michaelficarra: I don't see a use case for arguments other than we don't have it there. I don't think it's interesting enough to add just because this |
| 18:50 | <Bakkot> | jridgewell that's a good example |
| 18:50 | <michaelficarra> | arguments.item(-1) is useful |
| 18:51 | <Bakkot> | michaelficarra only if you have an arguments object, which, why do you have an arguments object |
| 18:51 | <michaelficarra> | because it's in-scope as `arguments` in every function invocation? |
| 18:51 | <jridgewell> | And it's the `Array.prototype.values` method, so shared between all `arguments` |
| 18:51 | <ljharb> | jorendorff: wait, what |
| 18:51 | <ljharb> | jorendorff: why would `item` accept anything that's not an integer |
| 18:51 | <michaelficarra> | jridgewell: that's great precedent! even if gross |
| 18:51 | <ljharb> | jorendorff: or at least a finite number |
| 18:52 | <Bakkot> | michaelficarra so? `eval` is in scope too, but, like, don't touch it |
| 18:52 | <michaelficarra> | sounds like we could probably do the same with Array::item |
| 18:52 | <jorendorff> | ljharb: I'm kind of saying I agree. just going by the slides |
| 18:52 | <devsnek> | michaelficarra: `...args` is an array that you can item(-1) on |
| 18:52 | <ljharb> | littledan: https://apidock.com/rails/Array/forty_two |
| 18:53 | <michaelficarra> | devsnek: can't always use rest parameters |
| 18:53 | <rkirsling> | I mean if we hit web compat issues with the Web APIs then *just* having a "from the right" method might suffice |
| 18:53 | <devsnek> | michaelficarra: why not |
| 18:53 | <Bakkot> | littledan I don't see why indexing with `-1` is any worse than indexing with `0` |
| 18:53 | <michaelficarra> | devsnek: use strict directive or weird parameter ordering conventions a la node |
| 18:53 | <michaelficarra> | Bakkot: +1 |
| 18:53 | <devsnek> | Array.prototype.item.call(arguments, -1) |
| 18:53 | <michaelficarra> | devsnek: yeah that's a decent alternative |
| 18:54 | <michaelficarra> | or the old reliable `args = [].slice.call(arguments)` |
| 18:54 | <ljharb> | RIP `arguments::Array.prototype.item(-1)` |
| 18:54 | <devsnek> | lmao |
| 18:54 | <michaelficarra> | ljharb: :'( |
| 18:54 | <haxjs> | Can we revive it? |
| 18:55 | <michaelficarra> | haxjs: it wasn't too popular |
| 18:55 | <howdoi> | ljharb: epic! self[41] |
| 18:55 | <littledan> | rbuckton: peek sounds like a great name |
| 18:55 | <leobalter> | picking the last item from `arguments` without checking the length sounds weird. For arguments you either expect a length or - if you expect many arguments - it feels like rest parameter is already a good design |
| 18:55 | <gibson042> | peek by convention is from the front |
| 18:56 | <ystartsev> | peek sounds too ambiguous to me |
| 18:56 | <devsnek> | https://apidock.com/rails/Array/forty_two |
| 18:56 | <gibson042> | x.peek(0) is like x[0] |
| 18:56 | <devsnek> | what does peek mean |
| 18:56 | <ystartsev> | i understand peek as similar to next, without advancing |
| 18:56 | <devsnek> | i only know it in the context of iterators |
| 18:56 | <gibson042> | it's actually a good candidate replacement for "item" if that name doesn't work out |
| 18:56 | <rkirsling> | peek is great if you're already a parser geek, but... |
| 18:56 | <rbuckton> | gibson042: that wouldn't match with `push` and `pop` being from the back and being queue-like operations on Array. |
| 18:56 | <littledan> | sorry don't worry about my concern about .item(-1), it doesn't seem really bad to me, ljharb makes a good point about .slice |
| 18:57 | <ljharb> | peek is like pop and push, it's just weird because arrays conflate Lists and Queues |
| 18:57 | <littledan> | I still like the idea of .lastElement() somehow or other |
| 18:57 | <rbuckton> | This proposal was already suggested in an issue on last: https://github.com/tc39/proposal-array-last/issues/27 |
| 18:57 | <ystartsev> | i think the concept is good |
| 18:57 | <devsnek> | ljharb: wdym "like pop and push" |
| 18:57 | <ystartsev> | i would support moving it forward |
| 18:57 | <ljharb> | devsnek: peek is "pop but don't remove it" |
| 18:57 | <rbuckton> | Well maybe not the same proposal, please ignore. |
| 18:57 | <devsnek> | ahhh got it |
| 18:57 | <gibson042> | peek is "next but don't remove it" |
| 18:58 | <devsnek> | yeah i wasn't sure what it meant on collection types |
| 18:58 | <ljharb> | arrays actually conflate the concepts of List, Stack, and Queue, i think? |
| 18:58 | <gibson042> | yeah |
| 18:58 | <ljharb> | pop/push, shift/unshift, and then everything else |
| 18:58 | <devsnek> | they're also dictionaries |
| 18:58 | <littledan> | +1 for Stage 1! |
| 18:59 | <rkirsling> | ship it |
| 18:59 | <devsnek> | [-1] for stage 1 |
| 19:00 | <jridgewell> | I think of arrays as being closer to stacks then queues |
| 19:01 | <devsnek> | they have the methods needed to be queues |
| 19:01 | <rkirsling> | jridgewell: I think performance encourages that view |
| 19:01 | <jridgewell> | Mainly because `shift` is O(n) and `pop` is O(1) |
| 19:01 | <devsnek> | yeah performance *definitely* is on the side of that |
| 19:01 | <rkirsling> | yeah. |
| 19:01 | <gibson042> | yep |
| 19:01 | <devsnek> | you could do a butterfly allocation for every array |
| 19:04 | <rbuckton> | jridgewell: agreed, I misspoke when I said "queue-like operations" above, I meant to say "stack-like operations" w.r.t. `push/pop`. Hence why I think `.peek` makes sense as "look at the nth element of the array starting from the last element". |
| 19:04 | <ljharb> | ystartsev: fwiw the motivation is to do it in node, and even if node is adding webcrypto, it seems like it should be in the language :-/ |
| 19:05 | <jridgewell> | Yah, I agree with `peek` being backwards looking for it |
| 19:05 | <devsnek> | crypto sounds good |
| 19:05 | <devsnek> | i still don't think uuid belongs in stdlib |
| 19:07 | <ystartsev> | ljharb: thats actually the argument we had regarding why it should be in webcrypto, node is implementing it |
| 19:07 | <michaelficarra> | shu: in case it was not obvious, I have an interest in attending that security model call |
| 19:07 | <ljharb> | ystartsev: ok but then that still means it wouldn't be portable outside browsers and node |
| 19:07 | <ystartsev> | rbuckton: we have already discussed it, we may rechartere it |
| 19:07 | <ljharb> | it's really weird imo for stuff that's not web-specific to only be in web specs. |
| 19:08 | <ystartsev> | ljharb: this is why i brought up a more wholistic approach to crypto |
| 19:08 | <ljharb> | gotcha |
| 19:08 | <keith_miller> | shu: Sorry, I missed part of this because I had a thingy. Was it discussed if we could have these be normative optional? |
| 19:08 | <rbuckton> | Given that NodeJS is also intending to implement something akin to Web Cryptography, I feel it might make sense to adopt part or all of Web Crypto in the language/standard library itself. |
| 19:08 | <ljharb> | ^ |
| 19:08 | <ystartsev> | the view of our security folks is that if we start introducing bits and pieces of crypto to just js, we should have a holistic picture so that we add things that are strateegic |
| 19:09 | <ljharb> | littledan: i'm not sure temporal is ready for wider review until the rate of change slows? |
| 19:09 | <ystartsev> | there was also discussion about moving web crypto to tc39, but it is blocked |
| 19:09 | <devsnek> | its worth noting that node and the web are not all of js |
| 19:09 | <devsnek> | just most of it |
| 19:09 | <ljharb> | ystartsev: phrased that way ("the view of" part) is quite compelling |
| 19:09 | <rbuckton> | ystartsev: Due to EventTarget, or for some other reason? |
| 19:09 | <ystartsev> | due to a process reason |
| 19:09 | <ystartsev> | i can raise it again, there was an ongoing discussion around this |
| 19:10 | <keith_miller> | ystartsev: Was it blocked becaues there are places where it doesn't make sense or because we don't want to be the arbiters? |
| 19:10 | <keith_miller> | IMO, I'm kind of a fan of standardizing many more things as normative optional and letting hosts define which things they should expose |
| 19:10 | <littledan> | ljharb: Temporal is seeking feedback, as announced in the presentation. |
| 19:10 | <rbuckton> | I'd be interested in knowing more, as I was asked by the committee to explore moving my `ArrayBuffer.getRandomBytes` proposal to bringing at least part of `crypto` to the language. |
| 19:10 | <keith_miller> | If we don't think they make sense everywhere |
| 19:11 | <shu> | keith_miller: what's normative optional? |
| 19:11 | <ystartsev> | therre were a couple of things -> one is that the layering and moving of bits of web crypto was offered by someone who was in an admin role but couldn't make that call |
| 19:11 | <shu> | keith_miller: .item()? |
| 19:11 | <keith_miller> | shu: no sorry, things like getRandomBytes |
| 19:11 | <shu> | keith_miller: oh i have no idea |
| 19:11 | <keith_miller> | where some contexts don't want it |
| 19:11 | <devsnek> | bradleymeck: did you pull the module string exports |
| 19:11 | <shu> | keith_miller: i'm kinda on the move to webcrypto train |
| 19:11 | <keith_miller> | because security or w/e |
| 19:12 | <ystartsev> | the second issue is that mozilla itself would be opposed to moving things out of web crypto as they see this as well defined and are being implemented by external consumers anyway (such as node) |
| 19:12 | <Bakkot> | workers don't expose most of crypto, for reasons which are totally unclear to me |
| 19:12 | <Bakkot> | they expose getRandomValues and nothing else, IIRC |
| 19:12 | <shu> | keith_miller: but i want the champions to hear that and respond, not me parroting them |
| 19:12 | <bradleymeck> | devsnek: arbitrary namespace bindings? nah, that went through |
| 19:12 | <keith_miller> | shu: One upside is that then node can share the spec |
| 19:12 | <keith_miller> | but I don't care too much |
| 19:12 | <devsnek> | bradleymeck: stage 1? |
| 19:12 | <devsnek> | oh i see it on the queue now |
| 19:12 | <bradleymeck> | `from ... import` has feedback that it doesn't carry enough weight so I'm de-prioritizing |
| 19:12 | <keith_miller> | I guess we can implement it in JSC regardless 🤷♂️ |
| 19:13 | <keith_miller> | Just feels like a failure of the language if the spec can't have "core" library features |
| 19:13 | <bradleymeck> | devsnek: no stage because i didn't ask, it should go quickly through staging though as it seemed only validity of strings is the question |
| 19:13 | <devsnek> | bradleymeck: like utf validity? |
| 19:14 | <bradleymeck> | yes |
| 19:14 | <rbuckton> | ystartsev: `UUID` is essentially dependent on `getRandomValues` (at least per the requirements of some members of TC39). Are you suggesting that `UUID` be moved from TC39 to a proposal to Web Crypto? |
| 19:14 | <devsnek> | js strings aren't required to be valid utf anything are they? |
| 19:14 | <ystartsev> | rbuckton: yse |
| 19:14 | <Bakkot> | devsnek indeed |
| 19:14 | <Bakkot> | but they are in many other languages |
| 19:14 | <keith_miller> | shu: Oh sure, I'm not saying they should feel obligated. Just that I think a lot of proposals don't come to TC-39 because of things like SES concerns, which I think is a shame. |
| 19:14 | <ystartsev> | rathre than move getRandomValues to tc39 |
| 19:14 | <michaelficarra> | devsnek: nope, just a sequence of UTF-16 code units |
| 19:15 | <devsnek> | so what's the problem then lol |
| 19:15 | <shu> | keith_miller: ah, interesting observation |
| 19:15 | <bradleymeck> | devsnek: exporting invalid stuff that other langs couldn't deal w/ |
| 19:15 | <keith_miller> | shu: if we could solve that via normative optional then we might have a better path forwar |
| 19:15 | <keith_miller> | forward* |
| 19:15 | <michaelficarra> | I'm glad we're getting to this editorial topic |
| 19:15 | <rkirsling> | oh man |
| 19:15 | <michaelficarra> | being an editor and all lol |
| 19:16 | <rkirsling> | most heated editorial topic ever |
| 19:16 | <rbuckton> | ystartsev: There's a broader question of whether there's the possibility of other ES standard library APIs that might depend on UUID, and then can't because it isn't specified. I suppose they would have to rely on merely a string or `ArrayBuffer` representation of the UUID. |
| 19:16 | <ystartsev> | rbuckton: are there specific apis you have in mind? |
| 19:16 | <rbuckton> | "might depend on UUID" in the future, rather. |
| 19:16 | <devsnek> | why would something have to depend on uuid |
| 19:17 | <gibson042> | shu: optional to implement, but if implemented must conform with the spec |
| 19:17 | <rkirsling> | definitely did *not* know about cbrt |
| 19:19 | <rbuckton> | ystartsev: Nothing concrete at the moment, no. I know that, in languages like C#, UUID (or rather, `Guid`) usage is fairly prevalent within the standard library. |
| 19:19 | <keith_miller> | devsnek: I don't think they are forced to be UTF-16 but it's a pain to do a lot of RegExp stuff if they're not in that form |
| 19:19 | <keith_miller> | If we didn't have non-unicode RegExp's with unicode characters then it would probably fine lol |
| 19:19 | <devsnek> | keith_miller: of course one *shouldn't* store nonsense in them |
| 19:19 | <ystartsev> | rbuckton: what kind of usage do we mean here? as a building block for other rthings? |
| 19:19 | <devsnek> | but one *can* |
| 19:20 | <keith_miller> | devsnek: store? |
| 19:20 | <keith_miller> | maybe we are talking about different things? |
| 19:20 | <rbuckton> | ystartsev: Yes. |
| 19:20 | <devsnek> | strings |
| 19:20 | <devsnek> | in js |
| 19:20 | <devsnek> | people used to store binary data in them before we got arraybuffer |
| 19:20 | <ystartsev> | rbuckton: from our perspective, it doesn't make sense in duplicating the standard, or having slightly different implementations of the same thing, or maintaining two implementations in parallel |
| 19:20 | <Bakkot> | fwiw I am in favor of requiring those strings to be valid UTF16 |
| 19:20 | <keith_miller> | I don't think it's the string so much as the code points |
| 19:20 | <Bakkot> | they're not arbitrary data; they're specifically an interop point, potentially with other languages |
| 19:20 | <keith_miller> | for regexps |
| 19:20 | <ystartsev> | rbuckton: i am unaware of any features that we are planning to add to js that would rely on uuid |
| 19:20 | <rbuckton> | I'm not opposed to UUID moving to web crypto, but I do wonder if we might have to revisit this again in the future. |
| 19:21 | <Bakkot> | and you can't export a dynamic string, so it's not like you have to check your strings or whatever |
| 19:21 | <devsnek> | Bakkot: a language may use a mangling scheme which is not valid utf |
| 19:21 | <Bakkot> | it would be an early error |
| 19:21 | <Bakkot> | devsnek ehhhhh |
| 19:21 | <devsnek> | i mean i doubt it exists |
| 19:21 | <Bakkot> | devsnek JS strings are not strings of bytes |
| 19:21 | <devsnek> | i don't see a reason to limit it though |
| 19:21 | <Bakkot> | they are strings of 16-bit values |
| 19:21 | <ystartsev> | i will see where the rechartering of webcrypto is at the moment, and i will get back to folks |
| 19:21 | <devsnek> | Bakkot: people used them as byte strings |
| 19:21 | <ystartsev> | the alternative is a holistic approach to crypto in tc39 that compliments web crypto |
| 19:21 | <keith_miller> | rbuckton: If we put UUID in W3C how would anything in TC-39 depend on it anyway? |
| 19:22 | <Bakkot> | devsnek yes, but this is an interop point, not an arbitrary string |
| 19:22 | <Bakkot> | devsnek the reason to limit it is so that the interop is "unicode strings" rather "sequences of 16-bit values" |
| 19:22 | <Bakkot> | if the strings were literally bytes, that might be reasonable, but they aren't |
| 19:22 | <Bakkot> | bytes are a kind of reasonable interop point |
| 19:22 | <Bakkot> | sequences of 16-bit values are not |
| 19:23 | <keith_miller> | i.e. I don't see how having TC-39 have it as normative optional would be different from a TC-39 use |
| 19:23 | <rbuckton> | keith_miller: As far as I can tell, we couldn't. At best, if we did need to support it we could depend on a uniform string representation of a UUID and users would have to depend on the host to give them a mechanism to generate one. |
| 19:23 | <rbuckton> | string or ArrayBuffer |
| 19:23 | <devsnek> | rbuckton: what is the use case that requires uuids |
| 19:24 | <devsnek> | vs some other somewhat unique value |
| 19:24 | <keith_miller> | rbuckton: I'd also be surprised since we can't add UUID to TC-39 we could add anything that depends on it |
| 19:24 | <rbuckton> | devsnek: I don't have one currently. I find myself often needing UUIDs in user code, and would find it acceptable if Web Crypto implemented UUID, as long as a compatible implementation is also available on Node. |
| 19:26 | <keith_miller> | ystartsev: I'd really like to see us consider normative optional before moving to WebCrypto but obviously I'm not championing the UUID proposal |
| 19:26 | <rbuckton> | My experience in C# has shown that `Guid` is often heavily used in larger programs and is tied to a number of standard library features in .NET. It would be unfortunate that we wouldn't be able to define something that is consistent and broadly available across all hosts, but it isn't the end of the world. |
| 19:27 | <keith_miller> | ystartsev: Not that you are either AFAICT, but you mentioned rechartering the group above |
| 19:27 | <ystartsev> | just a sec |
| 19:27 | <keith_miller> | no worries |
| 19:28 | <Bakkot> | rbuckton fwiw I think that's a C3-specific thing |
| 19:28 | <Bakkot> | *C# |
| 19:29 | <Bakkot> | I don't think Guid gets a lot of use in random programs in other languages |
| 19:29 | <rbuckton> | It's also a C++/MFC thing, heavily steeped in the fact that much of the Windows registry is built around GUID/UUIDs |
| 19:30 | <devsnek> | i've literally never seen UUIDs used outside of databases |
| 19:31 | <rbuckton> | devsnek: You pretty much can't write a shared Windows native library without them, though in recent years its not as obvious to the user. |
| 19:31 | <devsnek> | ah there's the problem |
| 19:31 | <devsnek> | i don't write shared windows libaries |
| 19:31 | <devsnek> | or libraries |
| 19:33 | <Bakkot> | jorendorff host hooks are "host-defined abstract operations" |
| 19:33 | <Bakkot> | that is the phrase used in the spec |
| 19:33 | <Bakkot> | I think this is equivalent to "AOs which start with the word Host" |
| 19:36 | <littledan> | should we go down the queue? |
| 19:51 | <Bakkot> | shu ljharb michaelficarra fwiw I am fine with writing down the thing Waldemar said and preserving that distinction |
| 19:51 | <shu> | yes, i was about to suggest that |
| 19:51 | <shu> | what waldemar is saying he finds it useful to editorially distinguish |
| 19:52 | <shu> | that is fine with me, as long as we get guidelines for editors to apply our judgment |
| 19:52 | <michaelficarra> | I don't fully understand what Waldemar wants |
| 19:53 | <Bakkot> | michaelficarra he wants us to only use "implementation-defined" when there is not a clearly correct answer |
| 19:53 | <michaelficarra> | still just an editorial distinction? |
| 19:53 | <Bakkot> | yup |
| 19:53 | <michaelficarra> | and we can still make it host-defined? |
| 19:53 | <Bakkot> | with committee approval, it sounds like |
| 19:53 | <michaelficarra> | aww |
| 19:53 | <Bakkot> | (that was chip's point) |
| 19:54 | <Bakkot> | (not waldemar's) |
| 19:54 | <rkirsling> | how does "implementation-dependent" as a phrase conjure up an image of "there is a best answer" |
| 19:54 | <ljharb> | to me, "dependent" and "defined" are identical |
| 19:54 | <ljharb> | like in terms of english words |
| 19:54 | <keith_miller> | You folks just play word games |
| 19:55 | <keith_miller> | Is that like words with friends? |
| 19:55 | <ljharb> | i mean, that's accurate |
| 19:55 | <gibson042> | I appreciate the distinction in of "defined" being specifiable and "dependent" not |
| 19:55 | <rkirsling> | ^ I'm okay with "defined" emphasizing a "definition" but |
| 19:55 | <ljharb> | regardless of the editorial category, the current wording is very unclear to me |
| 19:55 | <ystartsev> | ok so my understanding of this proposal is doing this: https://github.com/tc39/ecma262/issues/1524 |
| 19:55 | <ystartsev> | oops |
| 19:55 | <ystartsev> | sorry |
| 19:55 | <rickbutton> | IMO, the editors have a specific role to play word games, that's like the point? |
| 19:55 | <ystartsev> | https://github.com/tc39/ecma262/issues/1524#issuecomment-611692464 |
| 19:55 | <ystartsev> | this |
| 19:56 | <ljharb> | rickbutton: that's a triple word score right there |
| 19:56 | <gibson042> | the collapse of a quantum superposition is experiment-dependent, but the result of a classical coin flip is experiment-defined |
| 19:56 | <ystartsev> | my question might not have been clear |
| 19:56 | <ljharb> | gibson042: how are those not the same, a classical coin flip still depends on quantum effects |
| 19:56 | <gibson042> | "classical" by definition excludes quantum |
| 19:56 | <ljharb> | ah k |
| 19:57 | <ljharb> | still not clear on the difference in the terms tho |
| 19:57 | <ljharb> | i just think "dependent" and "defined" don't actually have different meanings conversationally, even if in C++ era languages they have a concrete meaning |
| 19:57 | <devsnek> | the point there is about causality |
| 19:57 | <ljharb> | and importantly, the spec currently does not have any normative distinction between them i'm aware of |
| 19:57 | <gibson042> | that part I absolutely agree with |
| 19:58 | <devsnek> | like engines don't choose what the cube root of a number is |
| 19:58 | <ljharb> | devsnek: they're allowed to, tho. |
| 19:58 | <devsnek> | i mean a real number |
| 19:58 | <michaelficarra> | note-takers (rricard): feel free to use point of order, that's why it's there |
| 19:59 | <gibson042> | nondeterminism would be more concerning in something specified as "implementation-defined" than something "implementation-dependent" |
| 19:59 | <shu> | michaelficarra: Bakkot: i did get the sense some delegates have a different notion of "normative" than narrowly scoped to "observably different" |
| 19:59 | <shu> | if normative expands to also capture intent |
| 19:59 | <shu> | that alarms me |
| 19:59 | <ljharb> | i don't see how anything is normative if you can't write a program that observes the difference |
| 20:00 | <gibson042> | but both out of scope for ECMA 262 anyway |
| 20:00 | <michaelficarra> | yeah I don't think everyone was fully prepared to have this conversation |
| 20:01 | <rkirsling> | ljharb: +1 |
| 20:02 | <shu> | Bakkot: excellent summary, thanks |
| 20:31 | <Bakkot> | shu I think it is less that there is disagreement about "normative", more that there are things which are not normative which people (e.g. Chip) feel should not be totally at the discretion of editors |
| 20:31 | <shu> | right, that's very sensible |
| 22:01 | <shu> | ystartsev: did you and keith schedule anything next week? |
| 22:19 | <keith_miller> | shu: Oh I thought it was gonna happen at the incubator meeting? |
| 22:20 | <shu> | keith_miller: wait -- the normative optional topic? no that wasn't my intention |
| 22:21 | <keith_miller> | Ah ok. Sure we can set something up. |
| 22:23 | <shu> | keith_miller: ystartsev: okay i'll set something up |
| 22:23 | <keith_miller> | Ok, thanks! are you gonna send us a doodles? |
| 22:23 | <shu> | yeah |
| 22:24 | <shu> | though that site is like, as much a cpu hog as VC software |
| 22:24 | <shu> | are there lighter doodle alternatives |
| 22:25 | <drousso> | shu i used <http://whenisgood.net>; a lot in college :P |
| 22:25 | <drousso> | much uglier, but still very functional and super lightweight |
| 22:25 | <keith_miller> | shu: I have it open and it's all of Safari is using 2% of CPU? Either I need to use your VC software or somethings weird in your browser... |
| 22:25 | <shu> | keith_miller: there are like 6 banner ads |
| 22:25 | <ljharb> | whenisgood is great |
| 22:26 | <keith_miller> | Oh, I have content blockers |
| 22:26 | <shu> | keith_miller: i support the hand the feeds me i guess... |
| 22:26 | <shu> | that* |
| 22:26 | <keith_miller> | Because I hate adds more than I want to support the web lol |
| 22:27 | <shu> | no judgment from me |
| 22:31 | <drousso> | shu you could always buy a Premium account for no ads :P <http://whenisgood.net/Pricing>; |