►
Description
Continuation of R&T/Box discussion (moved from 2021-07-28)
Regarding Node.js relaxing its code contribution guidelines around defense against mutation to intrinsics, at the expense of 10% performance and a considerably higher bar for contributors. We conclude that we might be able to make direct use of intrinsics more ergonomic while addressing the concern of safely discovering original intrinsics.
Continued conversation about naming Realms. We arrive at the idea of pairing a taxonomic name with a behavioral name, like ModuleGlobe (née Compartment), IntrinsicsSystem, SharedUniverse, ProcessMultiverse, &c.
A
All
right
welcome
to
the
sess
meeting.
We
have
two
items
on
the
agenda,
the
first
of
which
bradley
has
brought
up
that
node
is
moving
away
from
from
well
I'll,
allow
bradley
to
introduce
and
and
then
when
nicolo
and
folks
and
I
arrive,
we
have
a
postponed
conversation
about
records,
tuples
and
boxes
bradley.
Would
you
like
to
is.
A
C
Sure
so
so,
nodes
tsc
has
been
moving
forward
with
trying
to
figure
out
what
we
want
to
do
with
regards
to
what
we
call
the
primordials
usage
primordials
in
node
are
essentially
a
sanitized
copy
of
the
common
intrinsics.
You
find
in
javascript
the
language
itself,
not
necessarily
node's
implementation
of
its
runtime.
C
A
B
B
C
C
For
example,
you
have
to
call
a
primordials
which
is
a
injected
lexical
variable,
primordials.arrayprototypemap
and
then
get
past
the
function,
my
array
and
then
all
the
other
parameters
that
you
want.
This
causes
problems
for
maintainability.
It
causes
problems
for
performance.
It
causes
problems
from
memory
usage.
C
C
C
If
we
want
to
use,
for
example,
for
of
so
we
don't
use
for
of,
we
don't
do
a
rady
structuring,
we
don't
do
a
variety
of
things
and
we
have
a
bunch
of
lint
rules
on
it.
Doing
so
prevents
basically
people
from
landing
prs
because
of
the
extreme
dialect
required
in
order
just
to
ship
basic
functionality
that
isn't
susceptible
to
mutated
globals.
C
C
This
basically
takes
your
prototype
method
and
changes
it
to
accept
a
first
parameter
being
the
this
value
doing
so
it
does
have
a
hot
path
in
v8
now,
because
node
mentioned
being
problematic,
that
hot
path
is
not
hot
enough
for
it,
even
even
with
a
compiler
optimization,
it
is
still
a
performance
hit
to
use.
How
much
is
never
going
to
be
fast
enough.
C
So
you
you
get
a
10
degradation
on
every
intrinsic
function.
Call
essentially
doing
this,
so
no
amount
of
hot
pathing
will
fix
that
10.
10
percent
is
the
hot
path
that
is
after
we
saw
a
five-time
slowdown
without
the
hot
path,
so
from
500
to
10
percent.
That's
that's
what
we
reclaimed
and
then
for
memory
usage.
C
There's
a
lot
more
allocations
due
to
the
wrapping,
and
it
makes
a
lot
of
gc
happen
because
you're
creating
extra
arguments,
objects
and
things
in
particular.
We
can't
use
the
default
arguments
object.
We
have
to
do
other
things
because
people
can
mutate
stuff
and
that's
no
good
and
so
we're
basically
creating.
B
B
C
C
B
B
C
Okay,
so
even
with
all
these
problems,
we
have
been
landing
and
enforcing
use
message
as
best
we
can
for
node's
core,
but
doing
so
is
not
worthwhile
potentially.
So
there
are
arguments
coming
from
node's
technical
steering
committee
that
maybe
we
should
do
something
else,
and
perhaps
even
stop
trying
to
be
robust
against
mutation
of
javascript
intrinsics,
in
particular
things
that
propagate
themselves
as
secure
run
times
like
dino,
are
not
robust
against
these.
C
They
are
also
susceptible
to
these
kind
of
injection
vectors,
usually
for
various
means,
but
on
the
counter
side,
browsers
at
least
for
javascript
intrinsics
are
robust
against
it.
They're
not
robust,
entirely
against
mutating
against
mutating
the
host
provided
primitives,
it's
a
complicated
situation
there.
But
yes,
so
that's
the
discussion
we're
having,
and
I
believe
we
have
a
meeting
set
up
for
next
week
in
one
of
the
issue
threads
to
discuss
it.
C
A
A
E
Yeah,
I
think
this
difficulty,
you
know
it's
also
been
faced
by
javascript
implementers,
who
tried
to
implement
built-ins
in
javascript
and
get
these
same
issues
which
they
can
solve
with
magic.
But
you
know
this
is
a
recurring
issue
that
lots
of
people
face,
and
I
think
we
should
ideally
make
a
language
kind
of
proposal
that
solves
it
in
a
more
comprehensive
way
than
adding
these
different
kinds
of
primitives
to
to
do
little
little
bits
of
it.
E
C
So,
just
because
we're
talking
about
getting
rid
of
primordials
doesn't
mean
we're
trying
to
make
node
less
robust
in
order
to
regain
these
performance
features.
There
are
a
variety
of
alternatives
from
lightweight
membranes
to
other
stuff
like
that,
but
essentially
running
our
code,
which
is
trying
to
be
robust
against
essentially
third-party
code.
C
We
need
some
level
of
robustness
through
primordials,
it's
done
by
dispatch.
If
we
do
something
like
a
lightweight
membrane,
where
we
copy
across
all
the
serializable
properties
and
send
it
to
another
realm,
that's
another
thing
we
could
do.
It
is
actually
enough
of
a
performance
problem
that
that
might
be
okay.
C
B
C
C
C
C
A
I
think
it
might
be
a
good
time
to
kick
off.
Oh
well,
I
we
don't
have
mathew,
so
this
is
probably.
This
is
still
not
the
ideal
time
to
have
a
conversation
about
records,
tuples
and
boxes,
but
I
want
to
make
sure
that
we
make
the
time
available
if,
if
there's
interested
in
having
a
preliminary
conversation,
otherwise
I'm
fine
with
having
this
I'm
fine.
A
Having
continuing
in
this
topic
to
answer
daniel
last
time
we
talked
about
scheduling
this,
I
shot
out
an
email
looking
to
find
a
time
when
we
had
a
quorum
with
both
mark
and
matthew
and
and
yourself
and
niccolo
and
yeah
and
and
and
matthew
has,
has
the
best
articulated
material
to
to
discuss
for
the
proposal
and
mathew
is
off
getting
married
and
he'll
be
back
soon.
Presumably
we
just
haven't
been
in
touch
with
him.
B
Yeah,
so
what
so?
Let
me
let
me
start
by
giving
some
thoughts
the
yeah,
I
think,
we've
made
it
clear
that
I
want
to
revisit
all
this
once
matthew
is
available,
but
the
my
all
of
my
problems
are
around
box,
and
it
strikes
me
that
the
conversation
around
box
is
kind
of
sandwiched
in
an
uncomfortable
middle.
B
A
E
So
we,
you
know,
we
didn't,
propose
no
direct
objects
and
records
and
temples
to
the
to
the
committee,
because
the
champion
group
is
really
not
in
favor
of
that.
For
the
for
this,
not
only
we
propose,
showing
you
know,
symbols
as
weak
map
keys,
and
we
got
this
negative
committee
response.
So
you
know
at
a
high
level.
I
don't
understand
what's
wrong
with
the
form
of
argument
that
these
two
things
don't
work
and
we're
trying
to
find
a
middle
point.
E
E
And
you
would
also
have
predicates
for,
like
record
dot
is
record
and
tuple
that
is
tuple.
The
only
the
the
sticking
point
seemed
to
be
this.
What
is
the
prototype,
and
you
characterize
the
prototype
as
dynamically
scoped?
I
think
when,
when
nikola-
and
I
were
were
thinking
about
that
further,
our
analysis
was
more
like
well.
This
is
just
as
dynamically
scoped
as
primitive
wrappers.
It's
like
quite
similar
yeah.
B
E
B
Think
that's
right.
I
talked
that
out
with
with
matthew
some
and
I
think
you're
right
about
that-
that
it's
not
that
that
it's
it's
treating
dot
as
a
you
know,
it's
treating
the
dot
the
way
primitives
treat
dot
as
a
special
form
in
the
code,
that's
in
the
code
with
the
dot
in
it.
That's
using
the
realm
of
that
code,
and
it's
a
little
bit
weird
that
it's
doing
that
on
objects,
whereas
till
now
it's
only
done
that
with
primitives,
but
it's
not
dynamic
scoping.
B
B
Okay,
hold
on
a
second-
let's
be
very
careful
about
this.
If
I'm
executing
code
in
realm
a
and
I'm
calling
a
reflect.2
prototype
of
where
the
where
let's
say
the
the
the
two
prototype
of
method
is
a
is
a
method
from
realm
b,
I
would
expect
the
prototype
to
be
looked
up
according
to
realm
b,
because
the
thing
being
that
the
it's,
the
two
prototype
of
method
itself,
that's
being
invoked.
That
would
that
would
be
bringing
the
realm
with.
E
E
F
B
No,
the
the
problem
is
that
the
if
records
and
tuples
are
primitives
if
the
primitives
can
in
turn
contain
powerful
things,
then
there's
a
tremendous
amount
of
existing
code.
That's
broken.
If
records
and
tuples
are
objects,
then
objects
being
a
structure
that
contains
powerful
things
does
not
break
all
of
that.
Existing
cavity.
B
E
B
Okay,
so,
first
of
all,
let
me
let
me
say
that
categoric
we're
doing
something
like
records
and
tuples
in
our
distributed
object
system.
We
call,
we
call
them
copy
records
and
copy
arrays,
but
they're,
basically,
objects
that
are
are
are
frozen
and
only
contain
string
named
own
innumerable
data
properties
and
therefore
are
suitable
for
being
passed
by
copy
when
communicating
between
between
between
vats
and
between
machines.
B
B
Pressing
security
concerns
and
robustness
concerns-
I
I
am
you
know
and
having
been
exposed
to
the
arguments
for
box,
I'm
just
not
finding
the
arguments
that
there's
that
there
needs
to
be
additional
notation
at
the
transition
from
immutable
to
mutable.
I'm
not
finding
that
motivating.
I'm
not
finding
a
case
in
our
code
where
it
would
have
helped.
E
Okay,
I
feel,
like
we've
gone
from
a
categorical
error
to
more
of
you
know
a
question
of
of.
I
don't
want
to
say
taste,
because
this
is
you
know
this
is
more
deep
than
taste
has
a
lot
of
implications.
The
notation,
but
I
feel
like
we're
not
at
a
point
right
now,
when
we're
seeing
like
okay
with
this
identity,
subjects
approach
we're
seeing
this
kind
of
fatally
bad
thing.
It's
just
there's
some
design
decisions
that
we
should
justify
and
consider
alternatives
to.
Is
that
accurate.
E
B
But
but
I
would
like
to
be,
I
would
like
to
understand
what
the
case
is
that
as
objects,
not
as
primitives
as
primitives.
Maybe
there
was
more
of
a
justification
for
wanting
to
have
a
notational
boundary,
but
as
identities
objects.
I
would
like
to
understand
what
the
argument
is
that
we
need
a
notation
boundary
at
the
transition
from
immutable
to
mutable,
as
opposed
to
just
a
predicate
that
something
is
transitively
immutable.
E
So
the
argument
for
this
is
another
experience
based
argument
and
I
think
actually,
when,
when
robin
ricard
can
come
to
another
one
of
these
meetings,
then
he
can
also
speak
to
this,
but
there
there
are
a
lot
of
these
immutable
data
structure.
Libraries
popular
in
javascript
today
and
users
frequently
report
this
issue
of
having
trouble
understanding
where
the
boundary
is
between
the
mutable
and
immutable
parts.
That's
why
we're
proposing
to
make
it
explicit.
B
B
Okay,
because
I
certainly
I
mean
I
very
I'm-
I'm
coming
coming
to
this
issue
from
a
point
of
extreme
sympathy
and
support
for
trying
to
make
programming
less
hazardous
and
if
the
lack
of
a
notational
boundary
is
introducing
a
hazard
that
a
notational
boundary
actually
fixes.
I'd
really
like
to
understand
that,
because
trying
to
reproduce
the
argument,
just
from
what
I
know
in
my
own
head,
I
wasn't
able
to
do
it
to
do
it.
I
don't
see
what
the
hazard
is.
E
D
E
Trying
to
make
it
so
that
we,
we
called
it
automatic
or
implicit
boxing
where
you
just
can
include
references
to
objects,
so
one
one
hazard
that
comes
up
in
any
kind
of
sample
code
that
you
try
to
write
is.
If
you
try
to
make
a
structure,
that's
a
bunch
of
nested
records.
You
might
just
forget
one
of
the
hash
signs
somewhere
and
make
it
contain
an
object
when
you
really
wanted
it
to
contain
a
record.
We
talked
about
previously
having
this
be
context,
sensitive,
the
syntax,
meaning
and
that's
a
bad
idea,
because
I.
B
E
E
B
I
I
see
the
point
you're
making
and-
and
I
see
also
why
the
point
comes
up
in
your
context
and
does
not
come
up
in
the
agoric
distributed
object
system.
So
that's
that's
interesting.
So,
yes,
good.
Thank
you
that
that
that
does
help.
The
reason
it
doesn't
come
up
for
us
is
that,
in
order
for
something
to
be
passable,
there
are
severe
constraints.
B
Basically,
a
possible
thing
can
only
contain
other
passable
things
and
passable
things
have
to
fall
into
one
of
a
number
of
categories
and
just
a
plain
object:
that's
not
frozen,
and
it's
not
anything
special
just
won't
be
considered
passable
and
when
you
try
to
pass
it
you'll
get
an
error.
So
so
so
the
the
hazard,
the
hazard
that
you're
raising
is
for
us
prevented
at
a
different
level.
So
that's
interesting
that
would
explain
why
I
have
not
encountered
it.
E
E
E
E
B
B
Does
that
that
yeah
I'm
holding
forth
on
on?
I
just
don't
want
to
imply
that
I
agree
with
the
conclusion
because
of
the
objections
to
box
that
I
have
not
been
raising
during
this
meeting
but
which
I
I
want
to
discuss
when
when
matthew's
back,
but
but
with
regard
to
explaining
what
the
motivation
is,
I
think
you've
succeeded
at
doing
that.
E
G
I
talked
to
some
people
internally,
and
I
also
there
is
one
comment
there
in
the
bike
chat
that
I
that
comes
from
massage
from
on
the
webkit
team,
which
I
believe
that
feedback
has
some
like
background
from
internal
discussion
right.
It's
just
assumption,
I'm
not
even
asking
if
this
is
true
or
not,
but
I
think
it
should
be
taken
into
consideration
as
messiah
just
suggesting
to
get
to
to
use
it
like
a
not
a
simple
name
to
avoid
the
cuteness
of
the
new
name
for
the
realms
api.
G
G
B
D
A
D
A
D
D
B
D
E
I'm
really
kind
of,
I
don't
think
we're
hearing
any
like
bad
faith
reasons,
I
think.
If
they,
if
they
wanted
to
complain
about
the
d8
conflict,
then
they
would
then
they
would
complain
about
it,
and
I
think
it
also
has
to
do
with
the
rejection
of
the
previous
realm
proposal,
which
didn't
have
caldwell
boundaries
and
so
the
boundary
really.
I
I
really
do
want
to.
G
So
wait,
wait,
there's
something
else
that
I
forgot
to
mention
sorry.
I
was
just
catching
this
information.
It
was
just
fetching
it.
There
also
seems
to
be
like
a
conflict
with
this
name,
not
only
on
d8,
as
brick
mentioned,
it
seems
there
seems
to
be
an
overload
in
like
browser
extension
contexts,
at
least
from
the
webkit
side.
G
I
haven't
explored
too
much,
but
there
seems
to
be
an
overload,
like
the
information
that
I
have
like
there
seems
to
be
an
overloaded
name
in
browser
extension
context.
So
I
believe,
when
you
have
a
context
when
you're
using
for
browser
extensions,
you
might
have
this
name
already
or
something
like
that.
I
need
to
do
a
role
of
full
investigation
on
how
this
actually
works
in
the
webcase
extensions.
I.
B
E
So
I
I
don't
think
it'll
be
productive
for
us
to
push
back
on
the
need
to
rename
realm.
I
think
we
should,
in
this
room,
try
to
come
to
a
group
initial
consensus
about
what
we
want
to
propose
to
the
community
and
then
post
that
on
the
issue
and
then
get
feedback
from
the
community,
and
I
think
we
should
do
this
within
a
week
or
so
you
know
we're
all
just
trying
to
unblock
this.
E
B
With
these
you
know,
nested
nested
containers,
the
finest
grain
being.
What
we
currently
call
the
compartment,
then
the
the
thing
we
currently
call
the
realm.
Then
the
thing
we
currently
call
the
agent,
which
is
probably
the
single
worst
name
in
the
universe
for
any
of
these
things,
and
then
the
agent
cluster.
G
G
When
I
was
talking
to
john
david
dalton
from
my
team-
and
we
had
some
discussions
where
he
had
like
some
pretty
convincing
arguments
for
using
a
therm
that
actually
would
fit
in
a
name
skin
scheme,
but
I
don't
think
the
name
would
be
very
appreciated
here.
So
that's
one
of
the
cons
like
the
name
itself,
I
don't
think
it's
going
to
be
the
most
loved
but
like
he
had
a
good
convincing
argument
for
using
verse
like
a
constructor
named
verse.
G
G
A
A
B
G
A
E
The
world
would
not
quite
meet
the
suggestion
that
the
mache
from
from
webkit
made
that
we
should
like
not
try
to
look
for
a
short
cute
term
and
instead
have
something
longer
and
more
descriptive,
because
this
is
more
like
an
expert
api.
But
I
don't
think
that's
necessarily
a
fatal
constraint.
The
the
one
thing
is
like
world
and
globe
sound
like
they're,
the
same
level
of
nesting.
To
me.
A
B
C
Yeah,
I
think
I
think,
going
straight
to
astronomy
and
things
like
that
might
not
be
the
best
way
to
do
it.
Astronomy
itself
does
have
this
kind
of
scheme
with
your
idea
of
your
local
body
and
you're,
more
remote,
michael,
I
think
you're
muted
so
like
they
have
local
cluster
and
things
like
that,
but
you
could
also
just
you
know
tack.
The
word
group,
on
top
of
one,
to
get
an
arbitrary
extra
level
of
nesting
and
things
like
that.
C
B
G
I'm
gonna
do
some
homework
reading
on
taxonomies,
and
by
going
deep
on
definitions
for
all
of
these,
I
still
want
to
get.
I
still
want
to
see
how
I
can
fit
verse
or
globe
or
and
word
on
top
of
it.
This
seems
like
for
me
a
little
bit
more
natural,
even
if,
with
all
the
other
things
around
it,
but
I
I
need
to
do
some
homework
and
come
in
with
like
a
solid
foundation
for
yeah.
E
G
Then
this
is
me
recognizing,
like
I'm,
considering
something
if
we
have
a
solid
foundation
on
this
taxonomy
like
if
we
have
a
name
scheme.
I
think
this
is
a
also
a
good
argument
like
if
we
mix
this
all
this
all
in
a
good
name
scheme.
That
would
be
good,
but
also
I'm,
as
I
told
I
also
want
to
bring
something
that
is
not
just
a
simple
name:
constructor,
but
a
double
or
triple
name.
E
E
The
feature
is
likely
to
only
be
directly
used
by
a
narrow
set
of
super
experts,
so
it
probably
does
not
need
a
concise
one
word
name.
If
that
name
is
kitsy
metaphor,
a
longer
more
descriptive
name
is
likely
to
be
better.
So
I
I
do
think
that
what
what
what
leo
is
saying
about
a
hierarchy
is
good.
I
I
think
verse
is
probably
too
too
short
and
confusing.
I
think
if
we
had,
you
know
something
worse.
E
A
Possib,
so
it's
also
possible
that,
having
a
name
that
uses
one
word
to
imply
the
taxonomy
and
another
word
to
imply,
the
differentiation
would
be
the
best
of
both
worlds
like
well.
I
mean
the
nice
thing
about
globe
is.
It
implies
both
global,
but
you
could
call
it
a
module
globe
if
you
wanted,
where
or
an
intrinsic
and
intrinsic
world
or
yeah.