2024-03-08
[18:40:14.0281] <Michael Ficarra>
so apparently Ecma has a lot of rules about their standards documents that we've been entirely ignorant of

[19:16:22.0100] <bakkot>
oh boy, definitely not doing that one

[20:41:57.0272] <Chris de Almeida>
is it... a standard for standards?  `/philosoraptor`

[22:34:28.0187] <ljharb>
rofl

[07:21:52.0557] <Michael Ficarra>
oh I forgot to mention that I will not be around for next week's editor call because I'll be at Wasm I/O

[10:31:16.0221] <shu>
i will incorporate a new legal entity just so i can fork the spec if we use commas for numbers


2024-03-13
[12:32:15.0078] <bakkot>
shu: let's cancel editor call today; michael's out and I'm having enough stabbing headaches already today without thinking about module loading or whatever

[13:44:42.0976] <shu>
bakkot: copy


2024-03-20
[16:58:48.0762] <Michael Ficarra>
okay after reading https://en.wikipedia.org/wiki/Decimal_separator I feel pretty strongly that we should not use comma for grouping (instead using space, following Ecma and many international standards bodies' recommendations) and I'm neutral between `,` and `.` for decimal separators


2024-03-21
[17:00:01.0782] <shu>
we should not change the number formatting at all from what it is

[17:02:55.0483] <Michael Ficarra>
pretty much all standards bodies agree though: General Conference on Weights and Measures, NIST, ISO 8601, ISO 80000-1, ...

[17:03:16.0941] <Michael Ficarra>
and of course standards daddy Ecma

[17:07:42.0008] <shu>
now that i've looked over it, there aren't that many large numbers

[17:08:05.0010] <bakkot>
I am categorically opposed to changing the grouping punctuator

[17:08:11.0754] <shu>
some of them would be clearer to be expressed directly as their formulas (e.g. 2^53, instead of writing it out)

[17:08:28.0676] <shu>
so i'd be open to removing some of them

[17:08:34.0600] <shu>
but otherwise not open to changing , to space

[17:09:44.0041] <shu>
i will change my mind when the whole of software engineering isn't so heavily american anglo-centric

[17:10:20.0551] <Michael Ficarra>
okay well hopefully they just never complain about it

[17:10:36.0951] <bakkot>
they haven't so far

[17:11:11.0718] <bakkot>
incidentally the HTML spec also uses american-style numbers (though in some cases they do not have a grouping separator)

[17:11:20.0453] <Michael Ficarra>
it's not just spaces btw, it's thin spaces lmao

[17:11:30.0997] <Michael Ficarra>
> The use of thin spaces as separators,[31]: 133  not dots or commas (for example: 20 000 and 1 000 000 for "twenty thousand" and "one million"), has been official policy of the International Bureau of Weights and Measures since 1948 (and reaffirmed in 2003) stating "neither dots nor commas are ever inserted in the spaces between groups", as well as of the International Union of Pure and Applied Chemistry (IUPAC),[32][33] the American Medical Association's widely followed AMA Manual of Style, and the Metrication Board, among others.

[17:15:17.0607] <bakkot>
thin spaces more tolerable than full-width tbf

[17:15:23.0570] <shu>
1░000░000░I░N░B░I░O

[17:24:33.0616] <Michael Ficarra>
god you are too online shu

[17:28:21.0702] <Rob Palmer>
Michael, you introduced me to "drip" so I suspect you of excessive onlineness too.

[17:28:39.0244] <Michael Ficarra>
I would never be online, sir

[17:54:57.0180] <Michael Ficarra>
also Ecma thinks sections shouldn't be nested more than 3 levels lol

[18:47:33.0375] <bakkot>
why does ecma hate organization

[19:44:44.0821] <Michael Ficarra>
I just noticed that the computed page numbers in the ToC are incorrect... 🤦‍♂️

[19:44:54.0280] <Michael Ficarra>
I'm getting really tired of Paged.js

[22:37:04.0451] <ljharb>
i think if we decide that usage stats of any number formats should be disqualified from any countries that gained their format by being conquered, the choice is obvious


2024-03-22
[18:45:47.0418] <Michael Ficarra>
k I think I'm done with the printing stuff for now

[18:45:53.0036] <Michael Ficarra>
you can review the status in https://docs.google.com/presentation/d/1kCDZewoWZtL26FnFSiK4tr6ZotGo7TR0_AZGlCwHiEQ/edit

[18:46:26.0106] <Michael Ficarra>
gonna add a short agenda item to present this to Samina and see what she thinks

[18:47:01.0622] <Michael Ficarra>
I think it's probably still not up to their standards and they're gonna want to go with a professional layout service, which is what we should have done from the start

[18:47:05.0817] <Michael Ficarra>
but we'll see


2024-03-29
[17:51:25.0884] <bakkot>
a large majority of RequireObjectCoercible calls are in String.prototype methods, as `1. Let O be ? RequireObjectCoercible(this value).`

[17:51:37.0241] <bakkot>
why did we design _strings_ to be subclassed

[17:53:14.0052] <bakkot>
`class Foo extends String {}` <- code written by the totally deranged

[19:30:47.0821] <Michael Ficarra>
blame the Smalltalk contingent (Allen)

[23:28:17.0864] <ljharb>
is it to be subclassed, or to be `.call`ed?

[10:02:29.0883] <shu>
beyond deranged

[10:24:32.0468] <ljharb>
yall really all prefer the string munging over a nice list?? i'm very surprised

[10:32:44.0862] <bakkot>
strings are lists

[10:34:04.0768] <Michael Ficarra>
yep and they have nice shorthands

[10:34:11.0154] <Michael Ficarra>
like "I am a string"

[10:34:19.0654] <Michael Ficarra>
and `the string-concatenation of`

[10:36:47.0092] <bakkot>
we do also have `the list-concatenation of`

[10:57:07.0741] <shu>
lists aren't nice

[10:57:14.0462] <shu>
I see a list and all I see are cache misses

[10:57:18.0977] <shu>
why is my Chromebook auto capitalizing wtf

[12:42:54.0177] <ljharb>
lol "strings are lists" is such a non-JS mental model, oh well

[13:24:46.0559] <Michael Ficarra>
> The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 2**53 - 1 elements.

[13:24:52.0297] <Michael Ficarra>
sounds pretty listy to me

[13:57:53.0590] <ljharb>
seems like 
```
Let _toEscape_ be StringToCodePoints(_punctuators_).
If _toEscape_ contains _c_ or _c_ is matched by |WhiteSpace|, then
```
seems like i can just skip the to code points step, since `_punctuators_ contains _c_` should be fine if punctuators is a string?

[14:01:32.0216] <bakkot>
no, since `_c_` is a code _point_ and a string is a list of code _units_

[14:10:11.0260] <ljharb>
ah, right, ok thanks