2023-11-06
[20:55:18.0446] <snek>
is human display for durations a solved problem anywhere? especially normalizing the units... 

[20:55:50.0847] <snek>
the more i think about this the more complex it gets and the less i am sure that it could be generally solved

[20:56:02.0420] <snek>
 * the more i think about this the more complex it gets and the less sure i am that it could be generally solved

[07:05:02.0756] <ryzokuken>
snek welcome to my world 

[07:05:52.0921] <ryzokuken>
the current version of the DurationFormat proposal can represent durations in mostly all forms that applications need 

[07:38:46.0029] <snek>
> <@usharma:igalia.com> the current version of the DurationFormat proposal can represent durations in mostly all forms that applications need 

does it support normalizing units? like if I just have a large quantity of seconds can it turn that into hours or weeks or whatever 

[07:58:04.0892] <ryzokuken>
> <@devsnek:matrix.org> does it support normalizing units? like if I just have a large quantity of seconds can it turn that into hours or weeks or whatever

weeeeell

[07:58:24.0233] <ryzokuken>
it can do that for subsecond units because those could be expressed as a fraction

[07:58:45.0618] <ryzokuken>
it could in the future do it up to hours

[07:59:41.0285] <ryzokuken>
but since a day may not have a set number of hours, it couldn't do further without a point of reference 

[08:01:37.0129] <snek>
it has a point of reference!! it's intl api!!!

[08:01:54.0802] <snek>
or do you mean a timestamp 

[08:02:00.0152] <ryzokuken>
no I mean a...

[08:02:01.0017] <ryzokuken>
yeah

[08:02:35.0123] <ryzokuken>
a `ZonedDateTime` for setting up the context for the calculations

[08:04:08.0782] <snek>
I guess I'll have to keep using the passable moment duration formatter 

[08:04:24.0401] <snek>
it has some weird behavior though 

[08:05:33.0628] <Andreu Botella>
I assume that wouldn't take leap seconds into account, right?

[08:05:41.0447] <Andreu Botella>
since IIRC UTC ignores them

[08:05:53.0483] <ryzokuken>
https://github.com/formatjs/formatjs/tree/d95d21f1ea10a190f45968e909323e9af6992921/packages/intl-durationformat

[08:05:56.0895] <ryzokuken>
there's this

[08:07:08.0926] <snek>
but if it doesn't normalize units it's not really usable 

[08:07:15.0077] <snek>
I just have a unix timestamp

[08:07:22.0720] <ryzokuken>
ah right

[08:08:01.0443] <pipobscure>
You surely have a timestamp and some second timestamp to get a duration.

[08:08:05.0643] <snek>
I guess that is sort of a distinct operation

[08:08:19.0040] <pipobscure>
The difference is your duration and one of them is your reference

[08:08:28.0580] <snek>
I have a unix timestamp and I want to display the duration between it and the current time

[08:08:54.0296] <pipobscure>
Which means the duration is now-ts and the reference is now

[08:09:04.0853] <snek>
today I use moment but moment is kind of mid

[08:09:07.0054] <pipobscure>
Which is enough to let it normalize units

[08:09:19.0576] <snek>
yeah if something implemented that

[08:09:33.0478] <pipobscure>
It’s just tha if you have ONLY a duration of 2234234seconds you can’t normalise

[08:09:53.0319] <snek>
yeah that's the problem 

[08:10:24.0595] <snek>
I just have a bunch of seconds. I want the computer to figure out the nicest way to display it, based on the users locale, reference point, or whatever else

[08:11:35.0300] <pipobscure>
Temporal.Duration.prototype.round should do that IIRC

[08:12:00.0928] <pipobscure>
And you can then send the result to Intl.DurationFormat

[08:13:04.0440] <snek>
hmmm

[08:13:13.0242] <snek>
that wants me to choose the unit though 

[08:13:27.0729] <ryzokuken>
https://tc39.es/proposal-temporal/docs/balancing.html

[08:14:29.0514] <ryzokuken>
the largest one 

[08:14:41.0110] <ryzokuken>
you can always go for `largestUnit: "years"`

[08:14:48.0925] <ryzokuken>
 * you can always go for `largestUnit: "year"`

[08:14:58.0667] <pipobscure>
The smallestUnit is optional I think

[08:15:18.0308] <devsnek>
oh it's just putting bounds on it I see

[08:15:48.0188] <pipobscure>
So with that combination of APIs you should be able to do exactly what you want. I think

[08:16:34.0325] <devsnek>
yeah that makes sense

[08:16:45.0873] <devsnek>
how many more years until ietf moves forward

[08:16:55.0459] <devsnek>
can we express it with Temporal.Duration

[08:24:20.0999] <ryzokuken>
> <@devsnek:matrix.org> how many more years until ietf moves forward

it's moved forward actually!

[08:24:32.0718] <ryzokuken>
we're planning to make an announcement at the next plenary

[08:25:19.0825] <snek>
I thought it was in a comment period for like 5 more months 

[08:25:27.0036] <snek>
pleasant surprise 

[08:25:35.0932] <ryzokuken>
it has been finally approved by the IESG

[08:26:04.0466] <ryzokuken>
https://www.rfc-editor.org/current_queue.php#draft-ietf-sedate-datetime-extended


2023-11-07
[03:07:09.0615] <littledan>
So... good to unplug??

[03:07:14.0298] <littledan>
 * So... good to unflag??

[03:11:25.0923] <ryzokuken>
> <@littledan:matrix.org> So... good to unflag??

Yes

[03:11:54.0593] <ryzokuken>
atleast the IETF blocker is no longer going to hold anyone back


2023-11-08
[16:44:13.0127] <tewuzij>
What is that blocker for?

[17:03:15.0221] <Chris de Almeida>
> <@tewuzij:tzchat.org> What is that blocker for?

Temporal stage 4 has been blocked by the IETF RFC mentioned above

[17:15:50.0614] <shu>
that... is not the only thing blocking temporal stage 4

[05:29:21.0604] <ryzokuken>
> <@shuyuguo:matrix.org> that... is not the only thing blocking temporal stage 4

yes

[05:29:34.0094] <ryzokuken>
to be more specific, shipping temporal unflagged was blocked on IETF

[05:29:49.0268] <ryzokuken>
which in turn was one of the multiple blockers to temporal getting stage 4

[05:30:41.0353] <ryzokuken>
but now that this blocker is resolved, temporal may start shipping in implementations whenever it's done


2023-11-10
[11:28:05.0832] <snek>
temporal isn't unflagged anywhere right

[11:28:17.0121] <snek>
can we change the Duration constructor to be an object

[11:28:22.0076] <snek>
this is unusable lol

[11:30:04.0421] <snek>
hmm i guess Duration.from is usable

[11:30:19.0391] <shu>
temporal is not even completely implemented anywhere afaik

[11:33:50.0443] <snek>
hmm v8 reverted durationformat

[11:34:06.0516] <snek>
with no reason given on the commit :>

[11:34:31.0965] <shu>
which commit are you talking about?

[11:34:52.0365] <snek>
https://chromium-review.googlesource.com/c/v8/v8/+/3932693

[11:36:23.0377] <shu>
that's the cherry-pick

[11:36:26.0525] <shu>
the original revert has the reason: https://chromium-review.googlesource.com/c/v8/v8/+/3925703

[11:36:38.0056] <snek>
oh i see

[11:36:39.0699] <snek>
how'd you find that

[11:38:21.0283] <shu>
the line 'Merged 931dbda07d22c4331d8b26158be00ef6c521a734'

[11:38:37.0263] <shu>
"Merged:" is chromium-ese for "back merge"

[11:38:42.0003] <shu>
that sha is the original commit

[11:58:27.0171] <bakkot>
> <@devsnek:matrix.org> this is unusable lol

oh jeeze why did we decide to do that

[11:58:30.0176] <bakkot>
I guess that's how Date works?

[11:58:37.0898] <bakkot>
but that is awful

[11:59:58.0291] <snek>
it seems to me like from() is really what you should use


2023-11-11
[20:40:06.0882] <Ashley Claymore>
Yeah the constructors are almost like an implementation detail, the static methods are the real API

[20:48:22.0515] <Ashley Claymore>
From the Temporal docs:

> Like all Temporal constructors, this constructor is an advanced API used to create instances for a narrow set of use cases.

[21:07:45.0407] <rkirsling>
I never thought to object to that but like

[21:08:50.0693] <rkirsling>
is the argument that you wouldn't need to create an object as a prerequisite for instantiating a Temporal class?

[21:42:09.0723] <Ashley Claymore>
I can see the advantage of keeping the actual constructors as simple as possible yeah. no object allocation, no chance of getters  

[21:42:42.0914] <Ashley Claymore>
(Simple computationally)


2023-11-14
[08:28:38.0916] <Jack Works>
question: why terser prefer `,` than `;`

[08:28:53.0137] <Jack Works>
```js
export function x() {
    a()
    b()
    c()
}
```

[08:29:07.0249] <Jack Works>
why
```js
export function x(){a(),b(),c()}
```
not
```js
export function x(){a(),b(),c()}

[08:29:14.0111] <Jack Works>
 * why

```js
export function x(){a(),b(),c()}
```

not

```js
export function x(){a();b();c()}
```

[08:40:15.0603] <bakkot>
Jack Works: probably because it works better in other contexts:

```
if (foo) {
  a();
  b();
  c():
}
```
can be minimized to `if(foo)a(),b(),c()`

[08:41:05.0776] <bakkot>
so if you're writing a minimizer you just have a rule which says that sequences of expression statements get collapsed with `,`, and then after having applied that rule sometimes you can eliminate `{}`s, whereas there's no place where using `;` instead of `,` is a benefit

[09:32:34.0865] <Jack Works>
oh, interesting

[09:32:56.0956] <Jack Works>
(because `,` is somehow harder to debug in devtools so I don't like it)

[09:35:54.0995] <bakkot>
https://unminify.io/ :)

[09:36:15.0408] <bakkot>
I haven't updated that in... I guess probably 5 years so it won't handle newer syntax

[09:36:47.0121] <bakkot>
but it does reverse that specific transform, among others

[09:48:20.0877] <Jack Works>
terser has an option to disable comma transform actually 

[10:33:10.0285] <eemeli>
Isn't it obvious that `,` is about half the size of `;`? `</tdz>`


2023-11-17
[23:39:55.0566] <annevk>
Is there something going on with tc39.es? I'm having a hard timing getting to the JS spec these days

[23:41:20.0338] <annevk>
Hmm, I wonder if it's Private Relay related

[23:55:25.0758] <bakkot>
annevk: it's just a github pages site with a domain, so if there's issues I'd expect you to have those on other github pages sites, or I guess if it's dns then to have it with other .es domains

[00:14:04.0303] <annevk>
bakkot: yeah not sure what it is, doesn't seem to be Private Relay


2023-11-18
[08:49:27.0205] <jmdyck>
Jack Works: When you introduce CoverXandY, you need to use it (instead of X or Y) in those contexts where the conflict/ambiguity exists. So if you're introducing CoverExpressionStatementAndWhatever, you'd have to change the Statement production to use that instead of ExpressionStatement. I think.

[08:49:42.0047] <jmdyck>
Mind you, I'm not sure you should be covering ExpressionStatement.

[08:51:53.0987] <jmdyck>
Seems like the conflict is with a CallExpression, so you need to bolt something onto CoverCallExpressionAndAsyncArrowHead.

[08:54:59.0205] <Jack Works>
but when it goes into the CallExpression, it is already inside an ExpressionStatement. can I go back and choose a different production (MatchStatement)?

[08:55:32.0399] <Jack Works>
* but when it goes into the CallExpression, it is already chosen to use ExpressionStatement. can I go back and choose a different production (MatchStatement)?

[08:58:12.0124] <jmdyck>
Sorry, I didn't mean a conflict with the whole of CallExpression, but rather with the part of CallExpression that CoverCallExpressionEtc deals with.

[08:58:54.0977] <jmdyck>
wait, no, you asked a different question.

[09:01:02.0494] <jmdyck>
You should look at how CoverCallExpressionEtc is used in the grammar. There's a use from CallExpression and one from AsyncArrowFunction.

[09:01:19.0698] <Jack Works>
Here is the full problem:
For code: match (expr)

if the following token is a {, then
    if this is parsing a statement (like "; match (expr) {"), then continue with the Match Statement
    otherwise continue with Match Expression (like "f(match (expr) {")
if it's something else, continue with CallExpression

[09:03:36.0458] <Jack Works>
I cannot add lookahead != `match` to Expression Statement so it's also a syntax ambiguity between match expression and statement 

[09:04:53.0479] <jmdyck>
Technically, I think it's a conflict, not an ambiguity. 

[09:05:18.0175] <jmdyck>
In an ambiguity, there would be 2 different ways to parse a whole text.

[09:05:45.0520] <Jack Works>
oh that's correct 

[09:06:54.0582] <jmdyck>
but it's true that you can't add [lookahead != 'match'] to ExprStmt

[09:06:56.0312] <Jack Works>
because there is a lookahead!=async function in ExprStmt so AsyncFnExpr won't conflict with AsyncFnDecl, in my case I cannot do this...

[09:07:37.0351] <Jack Works>
hmm maybe I can use the syntax parameter to do it?

[09:08:13.0770] <Jack Works>
ExprStmt uses ~MatchExpr, and all other references to Expr/AssignmentExpr uses +MatchExpr

[09:08:41.0596] <Jack Works>
then I can resolve the conflict between Match Stmt and Expr

[09:09:34.0026] <Jack Works>
but Stmt with Call is still a problem 

[09:09:50.0410] <jmdyck>
hm, you need both MatchStatement and MatchExpr?

[09:10:31.0064] <Jack Works>
yes, at least I hope. Stmt version can contain statements, where the expression version don't.

[09:10:47.0458] <Jack Works>
if we have do expression, I can remove Stmt version 

[09:11:39.0467] <jmdyck>
That complicates things, I think.

[09:13:13.0119] <Jack Works>
🤔

[09:15:59.0642] <jmdyck>
Isn't there an actual ambiguity between MatchStmt and MatchExpr?

[09:16:43.0911] <Jack Works>
hmm yes. 

[09:16:50.0409] <jmdyck>
like if you wrote a MatchStmt but all its statements happened to be ExprStmts, wouldn't it also look like a MatchExpr?

[09:17:11.0223] <Jack Works>
but Stmt can only appear at a Stmt position, is that really a problem?

[09:18:16.0654] <jmdyck>
I think I'd have to look at the syntax for MatchStmt and MatchExpr

[09:18:29.0393] <Jack Works>
I hope I can prevent ExprStmt parse Expression that Expression is a sole match expr, so there is no ambiguity in that position 

[09:19:31.0117] <Jack Works>
for this code:
match (expr) { default: { x }}

it's ambiguity, a block with ident ref "x" in Stmt version and an object literal in expr version 

[09:20:37.0868] <Jack Works>
ok I admit this is not ideal either

[09:21:13.0314] <Jack Works>
I should discuss it in the pattern matching champion group to see if we can do things in a unified way

[09:23:03.0767] <jmdyck>
This is https://github.com/tc39/proposal-pattern-matching ?

[09:23:07.0699] <Jack Works>
for example, use this production. but this basically means we reinvented the Do Expression proposal 

default: Block
default: [lookahead != `{`] Expression

[09:23:45.0932] <Jack Works>
> <@jmdyck:matrix.org> This is https://github.com/tc39/proposal-pattern-matching ?

yes, I'm working on the new spec (there is a PR).

[09:24:53.0690] <jmdyck>
ok, i'll try to look at it when i get some time.

[09:25:54.0951] <jmdyck>
(gotta go now)


2023-11-19
[09:12:56.0859] <Jack Works>
https://marketplace.visualstudio.com/items?itemName=MagicWorks.ecmarkup
New version released!

[09:14:19.0718] <Jack Works>
hover (only support info from @tc39/ecma262-biblio)

[09:15:20.0487] <Jack Works>
AO completion

[09:17:27.0241] <Jack Works>
Production completion

[09:18:18.0516] <Jack Works>
local variable completion

[09:19:59.0238] <Jack Works>
also intrinsic and well-known symbols

[09:20:48.0696] <Jack Works>
Note: this is for proposals, may not work correctly for the 262 repo. but syntax highlight and AO highlight should work

[15:13:37.0998] <jmdyck>
Jack Works: where can I see a rendered version of the new-spec branch?


2023-11-20
[17:56:10.0504] <Jack Works>
> <@jmdyck:matrix.org> Jack Works: where can I see a rendered version of the new-spec branch?

https://htmlpreview.github.io/?https://github.com/tc39/proposal-pattern-matching/blob/new-spec/index.html

[02:31:18.0649] <mika_akizuki>
I was just having a bit of thought about allowing the await operator to be suffixed rather than prefixed (e.g. like `.await` in Rust).

[02:31:21.0278] <mika_akizuki>
 * I was just having a bit of thought about allowing the await operator to be suffixed rather than prefixed (e.g. like `.await` in Rust)

[02:34:32.0109] <mika_akizuki>
This could make chaining more readable, for example
```js
// before
(await fetch()).props
await (await someAsyncMethod()).someReturnedAsyncMethod()

// after
fetch().await.props
someAsyncMethod().await.someReturnedAsyncMethod().await
```

[02:34:58.0967] <mika_akizuki>
 * This could make chaining more readable (reduced the need for parentheses), for example

```js
// before
(await fetch()).props
await (await someAsyncMethod()).someReturnedAsyncMethod()

// after
fetch().await.props
someAsyncMethod().await.someReturnedAsyncMethod().await
```

[02:36:30.0785] <nicolo-ribaudo>
That feels similar to https://github.com/tc39/proposal-wavy-dot

[02:45:03.0859] <mika_akizuki>
Hmm, I didn't notice that. It is similar, but I think spelling out `.await` is a bit more readable than `~.`?
There is another example:
```js
async function someFunc() { /* do something and returns 3 */ }
// This produces the intended behavior though to me it feels somehow odd
await someFunc() + 5



[02:45:42.0541] <mika_akizuki>
 * Hmm, I didn't notice that. It is similar, but I think spelling out `.await` is a bit more readable than `~.`?
There is another example:

```js
async function someFunc() { /* do something and returns 3 */ }

// This produces the intended behavior though to me it feels somehow odd
await someFunc() + 5

// This is feel more natural since it is certain that we get an awaited result and added it by 5
someFunc().await + 5
```

[02:45:55.0121] <mika_akizuki>
Purely my opinion though

[02:45:59.0379] <nicolo-ribaudo>
Spelling out .await is already valid JS code, so we'd need different syntax anyway 

[02:46:24.0380] <nicolo-ribaudo>
```
var o = { await: 2 }
var two = o.await;
```

[02:47:03.0183] <mika_akizuki>
Oh, I incorrectly assumed that await cannot be used as a field name, my fault

[02:47:27.0877] <mika_akizuki>
Then maybe yes, the wavy dot is kind of what I wanted

[08:14:06.0402] <Jack Works>
> <@jmdyck:matrix.org> Jack Works: where can I see a rendered version of the new-spec branch?

 * https://raw.githack.com/tc39/proposal-pattern-matching/new-spec/index.html

[10:55:41.0893] <TabAtkins>
The pipeline operator ends up solving this as well - `fetch() |> await ^^ |> ^^.props`, etc

[14:51:55.0349] <ljharb>
or even `await fetch() |> ^^.props`, i think

[15:04:55.0083] <Mathieu Hofman>
Yeah pipeline operator removes some of the motivation for wavy-dot

[15:36:47.0529] <jmdyck>
Jack Works Disallowing (somehow) an ExprStmt that consists solely of a MatchExpr would avoid the ambiguity with MatchStmt, but there would still be conflicts between MatchStmt and any ExprStmt that *starts* with a MatchExpr.

[15:57:59.0916] <snek>
is it even possible to disallow it in that way, without infinite lookahead or smth?


2023-11-21
[17:34:18.0748] <jmdyck>
I think it's possible with a grammatical parameter. 

[17:37:51.0321] <jmdyck>
ExprStmt would use (say) Expression[~MatchExpr], everywhere else would use Expression[+MatchExpr], and PrimaryExpr's RHS for MatchExpr would be guarded by [+MatchExpr] 

[17:38:15.0924] <jmdyck>
Feels a bit icky though.

[17:42:25.0547] <jmdyck>
 * ExprStmt would use (say) Expression\[~MatchExpr\], everywhere else would use Expression\[+MatchExpr\], and PrimaryExpr's RHS for MatchExpr would be guarded by \[+MatchExpr\] (This is roughly what Jack Works said a couple days ago.)

[17:44:42.0618] <jmdyck>
(You could probably modify the propagation of the parameter so that it means more like "can [not] start with a MatchExpr", to address the conflicts I brought up.)

[18:31:12.0080] <TabAtkins>
yeah, depends on how you're writing and whether you know you're awaiting ahead of time or not


2023-11-23
[20:26:10.0801] <bakkot>
Jack Works: do you want to talk about and/or demo your ecmarkup plugin during the start of the plenary meeting next week? not everyone reads this channel and it would be a good way to make people aware of it

[20:26:57.0182] <bakkot>
I expect the 262 editors' update will not take its full time slot, so there will probably be time in the agenda right after that

[22:09:46.0885] <Jack Works>
> <@bakkot:matrix.org> Jack Works: do you want to talk about and/or demo your ecmarkup plugin during the start of the plenary meeting next week? not everyone reads this channel and it would be a good way to make people aware of it

yes! I'm happy to do that

[22:16:14.0150] <bakkot>
Jack Works: excellent; I put a placeholder at the end of the editor update slides to remind me