| 00:00 | <sirisian> | bakkot: , Grammar/engine question on an idea I've had in my issues for ages. Related to this issue: https://github.com/sirisian/ecmascript-types/issues/79 Basically say an engine is aware of types, could it handle transferring the type to argument expressions. f(a:uint64){} and you called f(2**63); The engine when parsing would choose the overload (in this case there's only one function) and propagate the type, so it's like f(uint64(2)**uint64(63)). |
| 00:03 | <jmdyck> | @tolmasky: I don't think the spec really says whether or not your global.Francisco = { } qualifies as an intrinsic. Personally, I'd call it one, I think. |
| 00:07 | <jmdyck> | See also https://github.com/tc39/ecma262/issues/1540 and the https://github.com/tc39/how-we-work/pull/64 that it links to. |
| 00:08 | <bakkot> | sirisian: a number of programming languages use the type of the position to determine the type of literals in that position, yes |
| 00:09 | <sirisian> | Which languages? |
| 00:11 | <bakkot> | offhand, C++? |
| 00:11 | <jmdyck> | tolmasky: Also https://github.com/tc39/ecma262/issues/2608 |
| 00:11 | <bakkot> | though I guess that's not quite how it works in C++ |
| 00:11 | <bakkot> | it just has implicit conversions |
| 00:11 | <bakkot> | but it amounts to much the same thing |
| 00:12 | <bakkot> | Rust, also |
| 00:13 | <bakkot> | https://doc.rust-lang.org/reference/expressions/literal-expr.html#integer-literal-expressions |
| 00:13 | <bakkot> |
|
| 00:14 | <sirisian> | Yeah, but you can't type a 100 digit number. The maximum literal it has is i128 and u128 suffixes? |
| 00:15 | <bakkot> | It is true that Rust's integer types are bounded; I don't understand what relevance that has to anything? |
| 00:15 | <bakkot> | The example you gave also had a bounded integer type |
| 00:16 | <sirisian> | yes, for the basic one. Inside of the issue I wanted this to work seamlessly for BigInt as well. |
| 00:17 | <sirisian> | Essentially a system where suffixes are never necessary. (Though some might find them simpler than casting?) |
| 00:18 | <bakkot> | I'm still not clear on what the relevance of integer types in Rust being bounded is. |
| 00:18 | <bakkot> | As it says, "If an integer type can be uniquely determined from the surrounding program context, the expression has that type" |
| 00:18 | <bakkot> | it's not based on how long the integer literal is, it's based on the surrounding program context |
| 00:19 | <bakkot> | so in principle they could have a BigInt type, and if you wrote let x: BigInt = 0, then that 0 would unambiguously be a bigint 0, so that's how it would be intepreted |
| 00:28 | <sirisian> | bakkot: I just meant Rust doesn't have a bigint literal format: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=43ea23caef0c68e25e5d7dbc23c07953 It says "integer literal is too large". In my proposal I'd want it to just work. (also I've never used rust, so ignore the other error) |
| 00:31 | <sirisian> | Yeah, ChatGPT uses parse_bytes to write this. It can code Rust better than me already. |
| 00:32 | <bakkot> | Yeah that's not a fundamental limitation, that's just because rust does not have BigInts built in |
| 00:32 | <bakkot> | they could have if they wanted to, it's not a fundamental limitation |
| 00:33 | <bakkot> | There is nothing that makes let x: u64 = 0 any easier to infer than let x: BigInt = 0 would be |
| 00:34 | <sirisian> | Gotcha. Okay that's promising then. Thank you. This is really easy btw if I'm not the one implementing anything. |
| 00:35 | <bakkot> | to be clear I should emphasize that engines are almost certainly not going to have built-in type checking, ever |
| 00:35 | <sirisian> | yeah, this has turned into more a thought experiment for me to unwind lately while watching TV. |
| 00:35 | <bakkot> | gotcha |
| 00:36 | <bakkot> | yeah looking at how other languages do type inference will probably be interesting to you then |
| 00:37 | <sirisian> | Yeah, was researching other languages the other day and found out Swift has return type overloads. Was thinking it would be too difficult or weird for a language to have those. https://github.com/sirisian/ecmascript-types/issues/78 |
| 00:39 | <sirisian> | (Though you can do something similar in a weird way in C++ that I never thought of) |
| 01:08 | <shu> | Richard Gibson: hm we should've put https://github.com/tc39/proposal-json-parse-with-source/issues/39 and https://github.com/tc39/proposal-json-parse-with-source/issues/35 on the agenda. the current draft spec can't be implemented |
| 01:08 | <Richard Gibson> | yep, I'm commenting now |
| 01:08 | <Richard Gibson> | and will have a normative fix for discussion in January |
| 01:09 | <shu> | excellent, thank you |
| 01:10 | <Richard Gibson> | MarkM begs a distinction between intrinsics and his own invention of “primordial” that I cannot explain, but the distinction might be germane here. |
| 13:12 | <tolmasky> | It's somewhat strange, because that definition refers to intrinsics as values, whereas above it was stated that Number.MAX_SAFE_INTEGER was an intrinsic, implying that there is kind of a dual definition, where it kind of also refers to keypaths. That is to say, clearly the %Array% function itself is a intrinsic, like if I were making a Map of intrinsics to their "names", but it would be weird to say the number 4 is also an intrinsic, just because %Uint32Array.prototype.BYTES_PER_ELEMENT% holds a 4. |
| 13:25 | <Richard Gibson> | that's an interesting distinction, but I think the claim that Number.MAX_SAFE_INTEGER is an intrinsic is just technically inaccurate. %Number% is an intrinsic object, and its primordial state includes a property named "MAX_SAFE_INTEGER" (that cannot be altered or removed, unlike e.g. its property named "parseInt"). |
| 13:31 | <tolmasky> | Right, so under that model, the value contained by both Array and Array.prototype.constructor, is the same intrinsic object, and the "Array" property contained by the global object, and the property key path "prototype.constructor" are primordial states of the global object and the Array intrinsic respectively |
| 13:32 | <tolmasky> | and there is no like specific terminology to refer to such a state (to clarify the reason for these question, i would just like to label things in an object viewer, so if it is "unaltered original and/or built-in thing, it might be highlighted blue for example) |
| 13:36 | <Richard Gibson> | isn't "primordial" that term? |
| 13:37 | <jmdyck> | %Array% and %Array.prototype.constructor% are the same, but Array and Array.prototype.constructor aren't necessarily the same, because the latter is Writable. |
| 13:37 | <Richard Gibson> | (as an adjective) |
| 13:39 | <Richard Gibson> | generalizing the "required to exist before any ECMAScript code runs" detail into a description of not just values, but also the state of their properties |
| 13:45 | <jmdyck> | The spec doesn't define/use "primordial", and terminology.md only defines it as a noun. You could use it as an adjective with the meaning that tolmasky is asking about, and people might get the right idea, but you'd want to define it to be sure. |
| 13:45 | <Richard Gibson> | agreed. But informally, we definitely reference "primordial state". |
| 13:49 | <jmdyck> | Yup, but note then that "primordial object" would mean something different from how terminology.md defines "primordial" (noun). |
| 13:52 | <jmdyck> | (An intrinsic that is inaccessible to ECMAScript code would be part of the informal "primordial state", but it wouldn't be "a primordial" according to the terminology.md definition.) |
| 14:07 | <Richard Gibson> | I suppose "initial state" is more clear anyway |
| 14:09 | <jmdyck> | Yeah, probably. |
| 14:23 | <tolmasky> | The live version of the spec on https://tc39.es/ecma262/ seems to not have a corresponding tagged version on github (the tags only go up to es2022, but the spec that is live online says ECMAScript 2023, and defines itself as the most accurate and up-to-date version, but I don't know how to find that on github since there doesn't even appear to be an es2023 candidate tag, is it just whatever is currently the main branch?) |
| 14:24 | <jmdyck> | yup |
| 14:26 | <tolmasky> | so the tag represents the "final" state of the version at the end of the year, and es20XX is a moving target throughout the year? |
| 14:28 | <jmdyck> | the es2023 tag won't exist until mid-2023, I think, when a version is cut for official approval by Ecma |
| 14:29 | <jmdyck> | es2022 tag is what was approved in July-ish of this year, I believe. |
| 14:31 | <jmdyck> | The online spec calls itself ES 2023, but note that it also says "Draft". |
| 14:54 | <tolmasky> | Gotcha |
| 14:55 | <tolmasky> | OK, one more weird terminology question, within Records, [[whatever]] are not "internal slots", but rather "fields". That is to say, descriptor.[[Value]] is not an internal slot access, but a "field access"? |
| 15:02 | <ryzokuken> | Yes |
| 15:14 | <jmdyck> | The [[Foo]] notation is used for various purposes in the spec: a field of a Record, an internal slot/method of an object, an attribute of a property, the [[Description]] of a Symbol. |
| 17:02 | <ljharb> | that's an interesting distinction, but I think the claim that Number.MAX_SAFE_INTEGER is an intrinsic is just technically inaccurate. %Number% is an intrinsic object, and its primordial state includes a property named "MAX_SAFE_INTEGER" (that cannot be altered or removed, unlike e.g. its property named "parseInt"). Number.MAX_SAFE_INTEGER is an intrinsic, but 4 alone isn't |
| 17:02 | <ljharb> | the intrinsics syntax in the spec (%a.b.c%) works for any value |
| 17:04 | <Kris Kowal> | That’ll be a more useful distinction when your get-intrinsics proposal reaches fruition. |
| 17:08 | <Andreu Botella> | I've been looking at the ShadowRealm HTML integration PR. Is it intentional that setTimeout is not exposed in the realm? |
| 17:36 | <Mathieu Hofman> | caridyis working on giving guidelines to implementations regarding which host API make sense to expose in ShadowRealm. A relevant issue is: https://github.com/whatwg/webidl/issues/1119 We actually discussed this in the SES meeting yesterday. I don't see a reason why setTimeout couldn't be exposed, but there may be complications when the argument is a string that needs to be evaluated. |
| 17:38 | <Justin Ridgewell> | Is there a matrix chat for module harmony discussions? |
| 17:38 | <Justin Ridgewell> | Have feedback from my team (which I could give here if there's not a dedicated channel) |
| 17:39 | <Kris Kowal> | #tc39-compartments:matrix.org is the place. |
| 17:39 | <Justin Ridgewell> | Thanks! |
| 17:53 | <jmdyck> |
That suggests that when a single value is accessible by two different 'paths', those are two different intrinsics, because the combinations are different. But I'm pretty sure the spec doesn't want us to think that. |
| 18:00 | <Andreu Botella> | caridyis working on giving guidelines to implementations regarding which host API make sense to expose in ShadowRealm. A relevant issue is: https://github.com/whatwg/webidl/issues/1119 We actually discussed this in the SES meeting yesterday. I don't see a reason why setTimeout couldn't be exposed, but there may be complications when the argument is a string that needs to be evaluated. [Exposed=*] works for interfaces, but not for methods defined in the global interface, as is the case for setTimeout |
| 18:01 | <Andreu Botella> | The HTML integration PR currently defines the self property algorithmically, which is something done with WebIDL for WindowOrWorkerGlobalScope |
| 18:03 | <Andreu Botella> | I guess the fact that this is methods of the global interface rather than entire exposed interface doesn't matter for SES purposes, but it might need some additional refactoring of the HTML PR |
| 18:18 | <Mathieu Hofman> | from my point of view, they're properties of the globalObject. As long as they're configurable without exotic behavior (aka actually deletable), I don't really care how they got there |
| 18:19 | <jmdyck> | But there are lots of intrinsic objects that aren't properties of the global object. |
| 18:37 | <Andreu Botella> | from my point of view, they're properties of the globalObject. As long as they're configurable without exotic behavior (aka actually deletable), I don't really care how they got there setTimeout is out of scope for the linked PR. |
| 18:39 | <Mathieu Hofman> | But there are lots of intrinsic objects that aren't properties of the global object. |
| 18:39 | <littledan> | AFAIK |
| 18:40 | <jmdyck> |
Ah, my mistake. |