00:02:33  * keith_mi_joined
00:07:53  * wuz_joined
00:12:20  * wuz_quit (Ping timeout: 250 seconds)
00:22:12  <devsnek>is there any normative definition of "the arguments passed to this function invocation"
00:22:34  <devsnek>i can't find anything and every usage of it seems to go against the behaviour of filling arguments with undefined based on the function's length
00:22:44  <ljharb>? isn't it like, the things in the invocation parens?
00:23:04  <devsnek>🤷
00:23:10  <devsnek>like i said i can't find any normative definition
00:25:35  <ljharb>devsnek: https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist leads to https://tc39.github.io/ecma262/#sec-ordinarycallevaluatebody which leads to https://tc39.github.io/ecma262/#sec-function-definitions-runtime-semantics-evaluatebody which leads to https://tc39.github.io/ecma262/#sec-functiondeclarationinstantiation which seems like it has the steps you're interested in?
00:25:53  <ljharb>there's 37 steps there so i'm not super sure
00:26:20  <ljharb>note that i wouldn't expect `arguments` to match the length, only to match the actual provided arguments
00:27:02  <devsnek>yeah i'm not talking about `arguments`
00:27:34  <devsnek>builtin function algorithms refer to both "the number of arguments passed for this function invocation" and "the arguments passed to this function invocation"
00:27:54  <devsnek>neither of them are actually specified but its pretty easy to see what they mean in context
00:28:42  <devsnek>the problem is that it feels like i need to store two copies of every function arguments list now. one for dealing with functions that want the raw list, and one for functions with use the more normal behaviour of arguments being filled in with `undefined`
00:30:51  <devsnek>String.fromCharCode, for example, has `...codeUnits` as the arguments, `1` as the length, so everything about it would suggest that calling it with no args would be like calling it with (undefined) but since other engines exist i know that's not right
00:40:13  <ljharb>devsnek: i'm not sure that's true - if you only store `arguments`, and then do something like `declaredArgumentNames.map((name, i) => ({ identifier: name, value: arguments.length < i ? arguments[i] : undefined }))` to get the function's argument bindings?
00:41:02  <ljharb>for a rest arg tho you'd do something like `Array.prototype.slice.call(arguments, i)`
00:41:17  <devsnek>https://github.com/devsnek/engine262/blob/master/src/intrinsics/StringPrototype.mjs#L85
00:53:28  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:55:29  * aki_joined
00:56:24  * akirosequit (Ping timeout: 268 seconds)
00:56:33  * aki_changed nick to akirose
01:05:58  * keith_m__joined
01:06:26  <rkirsling>created https://github.com/tc39/ecma262/issues/1392
01:06:34  <rkirsling>^ ljharb cloudshu (and also bradleymeck jmdyck )
01:09:45  <ljharb>rkirsling: so, `try {} catch (e) { for (var e of whatever) {} }` works fine for me in safari
01:09:50  <ljharb>where does that error?
01:09:58  <ljharb>ah, you documented it, nvm
01:11:44  <rkirsling>yeah I didn't implement that piece because the parser doesn't currently know whether we're for-of or for-in at the time of that `var e`
01:11:57  <rkirsling>*didn't yet
01:12:12  <rkirsling>...so it's convenient that this discussion came up ;)
01:12:12  * not-an-aardvarkjoined
01:41:26  * keith_m__quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:01:16  * aki_joined
03:02:24  * akirosequit (Ping timeout: 258 seconds)
03:02:24  * aki_changed nick to akirose
03:16:25  <rkirsling>^ just put up a concrete proposal for the above since it's quite simple
03:16:51  <rkirsling>(we can obviously still discuss any conceptual objections on the issue thread)
03:31:51  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
03:46:01  <Bakkot>ljharb: might have missed this in scrollback, but in case this has not yet been clearly stated, the reason catch bindings are weird is that in `try { throw 0; } catch (e) { var e = 1; }`, the `var e = 1` declares one variable and writes to _a different variable_
03:47:18  <Bakkot>similar thing happens for `with({e: 0}) { var e = 1; }`, but of course it's not possible to statically prevent that case
03:47:57  <devsnek>does anyone know where the spec talks about filling in arguments to builtin function calls with `undefined` based on the length
03:48:00  <devsnek>i can never find the section
03:49:21  <jmdyck>https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
03:49:30  <jmdyck>4th para
03:49:55  <devsnek>thank you very much
03:50:05  <jmdyck>unless otherwise specified!
03:51:14  <devsnek>i'm changing all the occurrences of "the arguments passed to this function invocation"
03:51:23  <devsnek>cuz its kinda hacky
03:51:36  <jmdyck>to what?
03:52:07  <devsnek>to using the number of arguments passed to this function invocation
03:53:20  <devsnek>also maybe you know the answer to this, everywhere that rest args are used in builtin functions, there's always an explicit step describing getting those args
03:53:48  <devsnek>like step one of https://tc39.github.io/ecma262/#sec-string.raw
03:53:54  <jmdyck>hm, no occurrences of "the arguments passed to this function invocation" exactly
03:54:16  <devsnek>+/i invocation/call
03:54:28  <devsnek>+/-
03:55:49  <jmdyck>so in String.raw, the alg still needs the arguments, not just the number of them.
03:55:57  <devsnek>yes
03:56:14  <jmdyck>so i don't see how you can do the substitution you described
03:56:23  <devsnek>no i was asking about step 1
03:56:27  <devsnek>why it exists
03:56:48  <jmdyck>ah
03:56:49  <devsnek>like nothing says "Let template be the first argument passed to this function call"
03:56:57  <devsnek>its implicit from the header
03:57:31  <jmdyck>i think there actually are some things like that...
03:58:21  <devsnek>no results for "first argument" in that position
03:58:57  <devsnek>there's also "number of arguments" and "actual number of arguments" even though they're used the same way
04:01:11  <devsnek>Array.prototype.unshift just says "Let argCount be the number of actual arguments." :(
04:03:04  <jmdyck>I'm not finding what I said, so probably imagined it.
04:03:26  <jmdyck>(other than the rest param cases you noted)
04:03:53  <devsnek>every builtin with ...args seems to have its own magic semantics approximating that the arguments matched by `...args` will not be `undefined` filled
04:05:03  <jmdyck>But yeah, I recall I was surprised at the vagueness of the semantics for invoking built-in functions.
04:05:56  <devsnek>this is the most annoying thing i've had with it so far
04:08:13  * wuz_joined
04:11:26  <jmdyck>It's well-defined down to the point that the built-in function's [[Call]] is invoked, but at that point it traverses this bubble of prose in 9.3 and 17 before it hits the algorithms that actually appear in the spec.
04:12:19  <devsnek>that's why i can never find that section lol
04:12:26  * wuz_quit (Ping timeout: 246 seconds)
04:15:25  * cloudshuquit (Quit: Connection closed for inactivity)
04:16:26  <jmdyck>Moreover, for the overloaded constructors (like Date and Array), there's some extra (non-algorithmic) logic to select the appropriate constructor-alg.
04:17:40  <devsnek>yeah those things are hecky
04:24:40  <jmdyck>Looks like that layer of vagueness has been there since the first edition (and was even vaguer).
04:25:50  <devsnek>time to refactor
04:26:30  <jmdyck>I'm guessing it hasn't ever been clarified because it was (perceived to be) kinda tricky for not much benefit.
04:30:23  <jmdyck>And leaving it vague allows some flexibility when it comes to specifying builtin func algs
04:31:13  <devsnek>vague is ok, but its just kinda confusing rn
04:31:39  <devsnek>if other engines didn't exist it would be reasonable to assume that String.fromCharCode(undefined) behaved like String.fromCharCode()
04:33:06  <devsnek>https://github.com/tc39/ecma262/pull/1394
04:35:10  <jmdyck>Well, that would be one reasonable possibility, but the problem is the concept of the number of arguments that "the function is specified to require" isn't well-defined
04:35:52  <devsnek>its specified in that paragraph
04:36:23  <jmdyck>hm?
04:37:25  <devsnek>i swear i just saw something that said `"length" defines the number of required arguments of a function` (paraphrase)
04:37:51  <devsnek>oh i saw this https://tc39.github.io/ecma262/#sec-function-instances-length
04:38:42  <jmdyck>"typical number", so doesn't synch with wording in 17
04:39:09  <devsnek>aha paragraph 3 of section 17
04:39:11  <devsnek>"For each built-in function, this specification describes the arguments required by that function and the properties of that function object."
04:39:17  <devsnek>i think that's as close as it gets
04:39:36  <jmdyck>also not well-defined is exactly what would constitute "specifying otherwise".
04:40:06  <devsnek>isn't that where hacky prose comes into play
04:40:56  <jmdyck>well, it could be done via prose or pseudo-code, the spec doesn't say.
04:41:13  <devsnek>maybe we can increase the specified behaviour of the [[Call]] and [[Construct]] of builtins
04:41:43  <devsnek>to basically this https://github.com/devsnek/engine262/blob/master/src/value.mjs#L263
04:47:28  <jmdyck>o wait, what i said before is wrong.
04:49:20  <jmdyck>The vagueness layer doesn't start till step 10 of https://tc39.github.io/ecma262/#sec-built-in-function-objects-call-thisargument-argumentslist
04:49:58  <devsnek>like i said above lol
04:50:06  <devsnek>it just kinda falls off a cliff there
04:52:24  <jmdyck>I'm not sure what the point of "an imp-defined manner that conforms to the specification of F" is. Does any implementation actually define that manner?
04:53:15  <jmdyck>Should there be variation between implementations on this point?
04:53:47  <devsnek>the specification of F is always section 17
04:53:51  <jmdyck>Certainly they can vary in how they accomplish it, but should there be any variation in the semantics?
04:55:46  <jmdyck>"the specification of F" probably refers to the algorithm (or whatever) for the function in 18-26
04:56:21  <devsnek>🤷
05:06:39  * aki_joined
05:07:52  * akirosequit (Ping timeout: 250 seconds)
05:07:53  * aki_changed nick to akirose
05:44:32  * jmdyckquit (Remote host closed the connection)
06:08:23  * wuz_joined
06:12:52  * wuz_quit (Ping timeout: 272 seconds)
06:55:33  <ljharb>Bakkot: i guess i don't understand why it wouldn't just overwrite the catch binding
07:07:25  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
07:08:58  <rkirsling>so `let e = 0; try {} catch (e) { var e; }` is a syntax error, while `var e = 1; try { throw 2; } catch (e) { var e = 3; print(e); } print(e);`prints 3 and 1
07:09:17  <rkirsling>hadn't fully thought about the latter case
07:13:40  * akirosequit (Ping timeout: 272 seconds)
07:14:40  * akirosejoined
07:15:24  <rkirsling>the catch param scope is just its own thing, and so I guess ideally we would preventing hoisting through it, but that would break the web, so the idea was to prevent as much as possible
07:16:02  <ljharb>ahh
07:16:07  <rkirsling>prohibiting `try {} catch ({ message }) { var message; }` (the result of PR #150) definitely seems good
07:16:25  <ljharb>devsnek: btw, with your recent pr, did you find the location where function signature conventions are discussed?
07:17:21  <ljharb>like what permits the spec to say "Object.assign (target, ...sources)` and have that map to argument 0 in target and 1+ in sources
07:25:09  <devsnek>ljharb: as far as i can tell neither that or regular named arguments are explicitly defined
07:26:11  <ljharb>interesting
07:26:23  <ljharb>i assume they are for runtime code; but not for spec functions
07:26:39  <devsnek>yes they have extensive specification for js source
07:26:46  <ljharb>we should probably add a section to https://tc39.github.io/ecma262/#sec-notational-conventions that talks about the spec forms
07:27:06  <ljharb>specifically i'm interested in whether a rest arg is a List or an Array (i assume a list)
07:27:09  <devsnek>and yeah they are `List` not arrays
07:27:20  <ljharb>where does it say that tho
07:27:33  <devsnek>hmm
07:27:38  <devsnek>technically i removed the stuff that said that
07:28:08  <ljharb>lol
07:28:26  <ljharb>i suspect that there are many "rest args" that didn't say that in the first place
07:28:40  <ljharb>that's why i'm thinking it should have an overarching notational convention
07:29:02  <devsnek>yes i agree
07:30:04  <devsnek>the key thing about the builtin rest args is that they don't get filled with `undefined` via function.length
07:30:26  <devsnek>i really really wish js had python's function annotations rn
07:36:10  * mgoljoined
07:53:41  <annevk>Domenic: arc and arcTo on canvas 2d context need to be in order; there’s a note in the spec about it (maybe source only)
07:54:34  <annevk>Domenic: and yeah, always random or always ordered applies here, but of course we have neither 😊
09:21:34  * aki_joined
09:21:47  * akirosequit (Ping timeout: 240 seconds)
09:21:49  * aki_changed nick to akirose
09:55:57  * howdoijoined
10:08:49  * wuz_joined
10:13:52  * wuz_quit (Ping timeout: 268 seconds)
11:28:46  * akirosequit (Ping timeout: 250 seconds)
11:29:19  * akirosejoined
12:38:19  * jmdyckjoined
13:36:01  * aki_joined
13:36:47  * akirosequit (Ping timeout: 240 seconds)
13:36:47  * aki_changed nick to akirose
13:38:14  * howdoiquit (Quit: Connection closed for inactivity)
13:55:59  * gibson042joined
14:15:56  * cloudshujoined
14:28:46  * wuz_joined
15:10:54  * jorydotcomjoined
15:29:30  * Havvyquit (Read error: Connection reset by peer)
15:31:33  * Havvyjoined
15:32:45  * Havvyquit (Read error: Connection reset by peer)
15:39:55  * Havvyjoined
15:41:14  * aki_joined
15:42:08  * akirosequit (Ping timeout: 245 seconds)
15:42:08  * aki_changed nick to akirose
16:29:01  * devsnekquit
16:29:23  * devsnekjoined
16:32:28  <devsnek>any bocoup people around? i'm wondering if test262-integrator is safe to use. it looks sorta unmaintained
17:05:54  * wuz_quit (Ping timeout: 250 seconds)
17:07:00  * wuz_joined
17:15:28  * wuz_quit (Ping timeout: 245 seconds)
17:23:37  * jwaldenjoined
17:45:50  * wuz_joined
17:48:46  * akirosequit (Ping timeout: 246 seconds)
17:48:52  * aki_joined
17:49:46  * aki_changed nick to akirose
17:55:11  * AtumTjoined
18:32:34  * wuz_quit (Ping timeout: 250 seconds)
18:44:02  * keith_mi_joined
18:55:50  * wuz_joined
19:54:37  * aki_joined
19:55:03  * akirosequit (Ping timeout: 245 seconds)
19:55:04  * aki_changed nick to akirose
19:58:21  <devsnek>jmdyck: do you think this is ok? "Builtin functions in ECMA-262 are specified by signature and normative algorithm. A function signature is comprised of named arguments, which may be optional or rest arguments. Optional arguments are specified with [ , _name_ ] and rest arguments are specified with ..._name_ .A function's <dfn>required arguments</dfn> are the named arguments not covered by optional or rest arguments. Unless
19:58:21  <devsnek>otherwise specified, a builtin function's "length" property is set to the number of required arguments it has."
19:58:45  <devsnek>hmm that kinda went over the irc limit lol
19:59:43  <jmdyck>They aren't all specified by a normative algorithm. E.g. a lot of the Math functions are specified by a set of constraints.
20:00:05  <devsnek>heck
20:00:41  <jmdyck>And Array.sort is a hodge-podge of algorithms and prose.
20:00:42  <devsnek>its also kinda annoying that "rest" isn't an adjective
20:01:16  <devsnek>is there a better term for this type of argument
20:02:20  <jmdyck>It's probably better if you refer to the things in the signature as parameters rather than arguments.
20:02:55  <devsnek>i wish we wrapped the paragraphs in the spec
20:04:33  <jmdyck>(I'm kinda glad we don't. If you're searching the source for a paragraph that contains some text, you can be confident that a potential hit won't be interrupted by a linebreak.)
20:05:23  <devsnek>but diffs and editing
20:05:51  <jmdyck>Yeah, I'll concede that it's a pain in some respects.
20:06:09  <jmdyck>But note that wrapping can have bad effects on diffs too.
20:06:37  <jmdyck>e.g. insert a word near beginning of para, and every subsequent line gets rewrapped.
20:06:58  <devsnek>wouldn't be any worse than the current thing :P
20:07:31  <jmdyck>some diff-ers would highlight just the insertion.
20:07:38  <devsnek>github usually does that too
20:07:40  <devsnek>hmm
20:08:04  <jmdyck>except that sometimes it doesn't, dunno why.
20:08:33  <jmdyck>(E.g., it didn't highlight the insertion of "if not covered by a rest argument".)
20:08:35  * wuz_quit (Ping timeout: 258 seconds)
20:09:09  <jmdyck>(resuming looking at your para...)
20:09:25  <devsnek>yeah that was the only thing i added
20:09:36  <devsnek>i guess i need a better term for that too
20:09:48  <TabAtkins>devsnek: Wrapping is good. Wrapping at a col limit is terrible, for multiple reasons of which jmdyck provided one. Wrap at sentence and significant phrase breaks, best of both worlds.
20:10:02  <devsnek>i think whatwg wraps like that
20:10:16  <TabAtkins>https://rhodesmill.org/brandon/2012/one-sentence-per-line/
20:10:16  <jmdyck>The distinction of "named argument" vs "rest argument" doesn't sound right, because a rest arg has a name too.
20:10:23  <TabAtkins>CSSWG does. WHATWG uses col-based breaking.
20:10:25  <devsnek>markdown lets you wrap at sentences
20:12:09  <jmdyck>(TabAtkins: I like linebreaking at sentence and significant phrase breaks too. I don't think I've ever seen it in anyone else's text though.)
20:12:35  <TabAtkins>It's feels weird at first! but good god it has so many benefits
20:12:41  <jmdyck>yup
20:12:52  <TabAtkins>really tho just the extreme diff-friendliness is enough all by itself imo
20:13:02  <TabAtkins>(example right at the beginning of the linked webpage)
20:13:22  <devsnek>i generally wrap my comments near the longest line in the same block :(
20:13:57  <jmdyck>devsnek: as a strawman, consider (plain vs optional vs rest) parameters
20:15:47  * wuz_joined
20:16:09  <devsnek>sgtm
20:16:17  <devsnek>those are all subsets of named parameters though
20:17:24  <jmdyck>The problem with defining "required arguments" is that readers might infer that they actually *are* required, i.e. that omitting them is some kind of error, which it isn't.
20:18:27  <jmdyck>In fact that's also a problem with defining "optional" args, since that suggests that the others aren't optional, whereas they are.
20:18:48  <jmdyck>But the latter I'm not sure we can get away from.
20:19:22  <devsnek>is there a way to use the formatting of signatures without using heading
20:19:31  <devsnek>can i pop it in a paragraph tag or something
20:19:44  <jmdyck>hm
20:20:27  <jmdyck>I don't think so.
20:20:32  <TabAtkins>"defaulted" args, not optional.
20:20:45  <devsnek>defaulted to what
20:20:56  <devsnek>aren't they explicitly not present
20:21:15  <devsnek>unless the function's length is overridden by one of those "The "length" property of Math.max is 1" things
20:22:23  <jmdyck>I think the only difference between "plain" and "optional" parameters is that the former contribute to the 'default' value of "length" property, and the latter don't. Semantically, they're treated exactly the same, aren't they?
20:22:44  <devsnek>yeah
20:22:52  <jmdyck>for built-ins that is.
20:22:55  <devsnek>but not being part of the length property means they don't get filled by undefined
20:23:08  <jmdyck>(For abstract operations, there *is* a distinction.)
20:23:17  <devsnek>they're the ones where the algorithm says "if _x_ is present, blah blah blah"
20:24:31  <jmdyck>So you don't think there's a case where an 'optional' param is ever set to undefined according to the missing arg rule?
20:25:45  <devsnek>there are cases
20:25:53  <devsnek>when the length property is explicitly overridden
20:26:20  <jmdyck>hm
20:26:58  <devsnek>well in theory that would be a case
20:27:05  <devsnek>i assume something like that exists in the spec
20:27:47  <devsnek>actually y'know what go figure :( https://tc39.github.io/ecma262/#sec-date.utc
20:28:45  <jmdyck>ah, length is 7.
20:28:55  <devsnek>but it still asks if they're present
20:29:01  <devsnek>so i guess they don't get filled
20:31:35  <jmdyck>In the constructor for Symbol, _description_ is optional, but there's no check for whether it's present, just for if it's undefined, so that's assuming that the optional param still gets the undefined-for-missing rule.
20:34:24  <jmdyck>Similarly String.prototype.endsWith's _endPosition_
20:34:43  <jmdyck>String.prototype.includes _position_
20:35:58  <jmdyck>String.prototype.indexOf _position_
20:36:26  <jmdyck>String.prototype.lastIndexOf _position_
20:36:53  <jmdyck>String.prototype.padEnd _fillString_
20:37:14  <jmdyck>String.prototype.padStart _fillString_
20:37:27  <jmdyck>well, that's enough for now.
20:38:25  <devsnek>so Date is the weird one
20:40:56  <jmdyck>well, checking if square-bracketed params are 'present' isn't weird. But having square-bracketed params at positions <= `length` is probably weird.
20:42:43  <devsnek>https://gc.gy/14339560.png
20:43:26  <devsnek>is there a tag i can use to prevent breaks inside those method signatures
20:43:57  <devsnek>aha `nobr`
20:45:29  <jmdyck>(looking at image now...)
20:45:44  <jmdyck>"Builtin" should be "Built-in"
20:46:17  <devsnek>i feel like the semantics of rest params are still lacking
20:46:18  <jmdyck>again, not always a normative algorithm.
20:46:56  <devsnek>maybe "behavior"?
20:47:56  <jmdyck>maybe just "and usually a normative algorithm". Or you could just leave out the algorithm bit
20:48:35  <jmdyck>E.g. "the specification of each built-in starts with a signature", or something like that
20:49:45  <jmdyck>You might want to avoid "signature" and just talk about the (clause) header.
20:55:03  <jmdyck>The phrase "would be written as" sounds like "a JS programmer could write...", whereas what you want to say is, this is how it would appear in the clause-header for that function in the spec.
20:55:33  <jmdyck>not sure how to say that well
20:56:45  <jmdyck>Need better distinction between "parameters" (which appear in the function's header), and "arguments" which appear in an invocation of the function.
20:59:19  <devsnek>hmmm
21:01:13  <jmdyck>The text should maybe say that these are notations that the spec uses to specify (part of) the behavior of built-ins, and aren't (necessarily) notations in the language itself. I think there are example wordings for this elsewhere in the spec.
21:04:26  <jmdyck>I find that text is usually clearer if you can change plurals to singulars, e.g. "A rest parameter collects ..." If you put it in the plural, then there's the possibility that a bunch of them are doing it collectively.
21:05:15  <jmdyck>For "named parameters not covered by optional or rest parameters", that's just the plain params.
21:06:08  <jmdyck>So rather than define "required params", just say "length" property is the number of plain params.
21:06:18  <jmdyck>(unless otherwise specified)
21:08:48  <devsnek>good catch
21:08:59  <jmdyck>then there's the last sentence
21:10:02  <devsnek>indeed, i changed `is` to `are`
21:10:43  <jmdyck>I don't think the current spec is clear what it means by the number of arguments that "the function is specified to require". Does it mean the number of args indicated by the value of the "length" property?
21:12:14  <devsnek>i define it in the first sentence
21:12:26  <devsnek>oh i need to flip that around sorta
21:12:31  <devsnek>to mention that things can override it
21:13:27  <jmdyck>And even if it did intend that, we've got examples of where parameters beyond the "length" number also need to get the missing-is-undefined treatment.
21:13:58  <devsnek>only Date right?
21:14:19  <jmdyck>no, Date is an example of something else.
21:14:46  <jmdyck>e.g. String.prototype.padEnd
21:15:23  <jmdyck>length is presumably 1, but you can't limit missing-is-undefined only to the first param
21:15:26  <devsnek>looks like a typo
21:15:35  <devsnek>bug/typo
21:15:50  <devsnek>should say if fillString is not present or undefined i guess?
21:16:06  <jmdyck>We could treat it as a bug.
21:16:33  <jmdyck>but I'd say that should be a separate PR
21:16:56  <devsnek>engines treat no arg and undefined the same :(
21:17:40  <jmdyck>for padEnd, you mean?
21:17:53  <ljharb>devsnek: they don't always; it depends on the method
21:17:53  <devsnek>ye
21:18:01  <devsnek>ljharb: for this one at least
21:18:02  <ljharb>i believe moving forward, we're trying to treat absent and undefined the same
21:18:24  <devsnek>i feel like this is moving into "bitten off too much" territory
21:19:17  <jmdyck>Well, if you don't bring "length" into it, it's more chewable.
21:20:17  <ljharb>devsnek: it seems like the first order of business is, specifying the notational conventions for method signature
21:20:18  <ljharb>s
21:20:43  <devsnek>gotta figure out what they are first
21:20:47  <ljharb>and that would unblock most of the changes in your current PR
21:20:49  <ljharb>lol, yes, exactly
21:21:16  <ljharb>noting that we have to allow for an algorithm to distinguish absence, from present and undefined, etc
21:21:56  <devsnek>i think the behaviour should be to check for "is absent or undefined"
21:23:26  <ljharb>for some methods. but for some it treats them differently
21:23:30  <ljharb>and that can't be changed or it'd break the web
21:23:37  <devsnek>oh yeah i mean for new stuff
21:23:43  <devsnek>since old stuff needs "is present"
21:24:25  <ljharb>new stuff generally just compares to undefined
21:24:42  <devsnek>which is incorrect if it also has [, this]
21:24:42  <ljharb>which is the same as "is absent"
21:24:54  <ljharb>true, if it's optional, you'd need to check both
21:24:57  <devsnek>well engines treat it that way
21:25:07  <devsnek>but that's not how its specified
21:25:11  <ljharb>altho we could easily write the notational conventions so that optional arguments get filled in with undefined too
21:25:17  <ljharb>and that'd probably allow for simpler spec text
21:25:19  <devsnek>but then they're present
21:25:46  <ljharb>right - but for new stuff, it should behave the same if it's absent, or if it's present and undefined
21:25:54  <ljharb>so there's no reason the methods should need to distinguish in the common case
21:26:21  <devsnek>so you're saying like
21:26:29  <devsnek>filled with undefined but can still be called not present
21:27:37  <jmdyck>(afk)
21:29:02  <ljharb>yes
21:29:39  <devsnek>sounds like ~magic~
21:30:07  <devsnek>and i'm reluctant to spec it that way because i can't think of a good way implement it in engine262
21:31:43  <ljharb>i mean, each named argument, optional or not, would get filled in as `undefined` if needed; and `arguments` would be created as needed, and you'd keep a mapping of argument names to arguments object indexes, and "if present" would check if the identifier's argument index was < arguments.length
21:43:30  * wuz_quit (Ping timeout: 246 seconds)
21:59:41  * wuz_joined
22:01:27  * aki_joined
22:02:52  * akirosequit (Ping timeout: 272 seconds)
22:02:55  * aki_changed nick to akirose
22:03:47  * wuz_quit (Ping timeout: 240 seconds)
22:08:15  <jmdyck>ljharb: are use suggesting that as a strategy for implementation or specification?
22:08:20  <ljharb>specification
22:08:24  <ljharb>or rather
22:08:31  <ljharb>sorry that last comment was for implementing it in engine262
22:08:39  <jmdyck>ok
22:08:44  <ljharb>for specifying it, it's probably enough to say "was provided"
22:09:03  <ljharb>or at least, i don't think specifying it's the hard part
22:20:51  * jorydotcomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:21:31  * jorydotcomjoined
22:24:01  * jorydotcomquit (Client Quit)
22:25:24  * jorydotcomjoined
22:25:41  * jorydotcomquit (Client Quit)
22:56:01  * AtumTquit (Quit: AtumT)
23:38:08  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:57:30  <rkirsling>cloudshu: hope I didn't miss the point of your example or anything :) the bit that Bakkot quoted occurs in two places and we can surely simplify the first one, but I'm a bit perplexed about the second one (for direct eval) due to what seems to be a spec/reality divergence
23:59:19  <cloudshu>rkirsling: it was just an oddity, no real point
23:59:50  <cloudshu>rkirsling: it's an example of the two annexes interacting in such a way that's weird
23:59:51  * wuz_joined