OCapN Pre-standardization Group

September 2024

Agenda

Minutes

Closed Issues

Christine: There haven't been any spec-relevant closed issues for a while.

Calling Conventions

https://github.com/ocapn/ocapn/issues/131

Kris: I've looked it over and we're in a good position to have a conversation

Jessica: This describes the Spritely and Agoric conventions. Last month we talked about strings vs. symbols/multiple operands/etc., and I also include a proposal here to "Continue with existing approach taken in current OCapN specification where methods are a convention of the first argument being a symbol [and] the handler/receiver may be implemented either as a function or an object with methods [and] if the sender/caller invokes a method and the handler/receiver is a function, the first argument will be conspicuously an OCapN symbol [and] if the sender/caller applies a function, passing an OCapN symbol as the first argument, and the receiver/handler is an object, the method with the corresponding string name will be invoked".

Kris: I want to come back to what to do in Haskell. But regardless, I think Agoric is prepared to agree to this, which for us means no longer supporting JavaScript Symbol.asyncIterator. Related, I have observed that registered symbols are problemetic for JavaScript, so OCapN symbols would most likely be objects, which will be awkward but mostly invisible to consumers because method names will be translated to strings. For OCapN, we will continue to have a single operator for invoking both functions and methods. But I would like to move for consensus on closing this issue.

Mark: If instances map in JavaScript to something other than the Symbol type, I think we would instead want a different term to avoid confusion. And I would propose "selector", which has some precedent in OO languages. Folding everything into just one kind of call is incompatible with the current shape of our eventual-send library, but I think Agoric can adapt. But it precludes a "function with methods" pattern that would otherwise be natural in E/JavaScript/etc. I want to make the costs on the Agoric side explicit before agreeing with Kris's position.

Christine: Jessica has been commenting in the chat and I'd like to hear more. Regarding the "selector" name, I'm comfortable but would hope for text explaining the mappings in languages such as Lisp.

Mark: To answer Jessica's question in chat, we would be renaming OCapN "symbol" to "selector" and would always be using that term even for non-initial operands.

Mark: JavaScript registered symbols in most if not all implementations are not garbage collectible and effectively constitute a permanent memory leak. I don't know if that's also the case for Lisp and Scheme implementations.

Christine: It sounds like everyone is fine with specifying symbols as reasonable mappings in various languages, so this works for me. The Lisps I have worked with (Guile and Racket) do GC symbols.

Jessica: I'm also happy with the "selector" name... it's a little confusing but not overly so. We should document abstract types at the top of the specification anyway.

Jonathan: In my implementations, symbols are garbage-collectible but IIRC it wasn't automatic. They're like weak pointers, and require a separate pass over the heap and somewhat more expensive as a result.

Kris: Things will be weird at the JS boundary, but I'm fine with that. Likewise Syrup and Preserves. If there's a resolution to change it, I volunteer to update the abstract types documentation.

Christine: What about the name "sym"?

Mark: I don't hate it. It's sufficiently different from "symbol" to avoid confusion in JS, although I still prefer "selector".

Christine: I bring it up for the historical connection, but also because it's a bit weird to allow "selector" after the first position. I don't really want to advocate for "atom" or [courtesy Baldur] "quark".

Jonathan: Let's vote in chat.

Christine: W3C conventions; +0/-0 express non-blocking preferences, +1/-1 express strong (possibly blocking) preferences.

Mark: I'm changing my vote... in the expected intersection across languages, given that this doesn't correspond to anything in non-initial position for at least JS, these are not likely to be used for anything other than method selection.

Type Naming Results

| Name           | Sym | Selector |
|----------------+-----+----------|
| Mark Miller    |  -0 |       +1 |
| Kris Kowal     |   0 |        0 |
| Baldur         |   0 |       +1 |
| Zachary Larson |  +1 |       +0 |
| Christine L-W  |  +1 |        0 |
| Juli           |  +1 |       -0 |
| David Thompson |  +1 |       -0 |
| Jonathan Rees  |   0 |       +1 |
| Jessica Tallon |  +0 |        0 |
| Erik Marks     |  -1 |       +1 |
Selector:
 +1: 4
 +0: 1
  0: 0
 -0: 2
 -1: 0
 
Sym:
 +1: 4
 +0: 1
  0: 3
 -0: 1
 -1: 1

Selector wins having no -1s

Back to the issue

Kris: I move for acceptance.

Mark: Second.

Christine: Second.

Christine: Clarification: it is still acceptable to pass selectors outside of first position.

Kris: Correct.

Christine: PROPOSAL: That we accept the current OCapN convention of having Selectors (formerly named "Symbols") be a convention corresponding to method invocation, with it still being acceptable to pass selectors outside the first position of an object invocation.

Jonathan: Without opposition, ACCEPTED: That we accept the current OCapN convention of having Selectors (formerly named "Symbols") be a convention corresponding to method invocation, with it still being acceptable to pass selectors outside the first position of an object invocation.

Should we adopt IDL?

https://github.com/ocapn/ocapn/issues/17

Jessica: I'm generally opposed, but interested in other viewpoints.

Mark: Users of OCapN are still free to use IDL for organizing their own systems, but OCapN itself is more dynamic than is generally a good fit.

Kris: I would frame this as a decision not to pursue the design of an OCapN IDL and to commit to a lack of requirement for an IDL.

Kris: I volunteer to document this as closed without prejudice.

What do we call a CapTP not-exactly-a-vat?

https://github.com/ocapn/ocapn/issues/18

Jessica: I wrote this without the "vat" model in mind; Goblins previously used "machine" but updated to "node".

Mark: I'm very much against "node" and don't really like "machine". What are the other candidates?

Jessica: "peer" has been suggested.

Kris: "interlocutor" ;)

Mark: I like "peer". It supports the story about this being a peer-to-peer computing platform. The problem with "node" is that it's so generic.

Jonathan: Absent objections, "peer" it is.

Adjournment

Christine: I can scribe next time.

chat transcript

[19:00] Welcome to OCapN!
For help on using BigBlueButton see these (short) tutorial videos.
To join the audio bridge click the phone button.  Use a headset to avoid causing background noise for others.
To join this meeting by phone, dial:
  +1-718-247-9666
Then enter 82190 as the conference PIN number.
[19:01] kumavis: guten tag
[19:01] Baldur: kveldið
[19:01] Kris Kowal: mae govannen
[19:01] Baldur: cryptpad?
[19:02] Baldur: still on ipad so no kb
[19:02] Christine Lemmer-Webber: I can do it if nobody else volunteers
[19:02] Jessica: hey sorry I'm late
[19:03] Christine Lemmer-Webber: https://cryptpad.fr/code/#/2/code/edit/Hl7R-bQgYwoVuDkfldWZXNSn/
[19:05] Baldur: issue #24 is more of an historical note though
[19:10] Baldur: I like it as it is rather simple to implement afaict
[19:11] Mark Miller: q
[19:12] Baldur: {"$sym":"foo"} kind of dealio?
[19:13] Christine Lemmer-Webber: what if we called it a "Sym"
[19:13] Baldur: merkill can be used instead if ya wanting to adopt newwording
[19:13] Jessica: do you have any suggestions mark?
[19:13] Baldur: selector works for me!
[19:14] Christine Lemmer-Webber: I'm okay with it as long as the documentation around "Selector" may acceptably be implemented as symbols in lisp-like languages
[19:14] Kris Kowal: OCapN
:name
would be JavaScript
{[Symbol.for('passStyle')]: 'symbol', symbol: 'name'}
[19:15] Christine Lemmer-Webber: q+
[19:15] Kris Kowal: albeit selector
[19:15] Kris Kowal: Pardon, 'name, not :name
[19:15] Kris Kowal: (Also not Ruby :name, same problem as JS :-P)
[19:15] Baldur: lingustic help: what does 'preclude' mean? answer in text chat
[19:16] Kris Kowal: preclude means to make impossible
[19:16] Kris Kowal: make impossible before the possibility can be realized, specifically
[19:16] Baldur: that gist I got
[19:16] Baldur: thx!
[19:16] Jessica: so we'd be renaming symbols in ocapn to selectors even where they are not used to select a method?
[19:17] Kris Kowal: Jessica: that is my understanding
[19:17] Baldur: syrup symbol != js symbols, afaik
[19:19] Baldur: or some Forth impls too
[19:19] Kris Kowal: The proposition is:
Scheme symbol is 'x
OCapN selector is Preserves notation 'x
JavaScript reification of OCapN selector is{[Symbol.for('passStyle')]: 'selector', selector: 'x'}
[19:19] David Thompson: so js has the symbol DOS problem that ruby used to have?
[19:19] Jessica: *accidently closed the wrong tab*
[19:20] Jessica: I'm okay with renaming symbols btw
[19:20] Christine Lemmer-Webber: they don't typically have that problem
[19:20] Kris Kowal: David: yes, JavaScript does not collect unreachable registered symbols
[19:20] Christine Lemmer-Webber: but it's not important specification wise
[19:20] David Thompson: symbols can be gc'd in the lisps I'm familiar with
[19:20] Baldur: same problem if the symbol interning tables are not ephimerons iirc
[19:20] Kris Kowal: Baldur: correct
[19:21] Jessica: q+
[19:21] Jonathan: gctwa  is old-fashioned tech for gc'ing symbols
[19:21] David Thompson: also non-lisps such as ruby will gc symbols
[19:22] Kris Kowal: q+
[19:22] Baldur: veljari is also on the table :3
[19:22] David Thompson: would we call all syrup symbols selectors now?
[19:22] Kris Kowal: q- (i’m also fine with ocapn calling these symbols, i don’t find the distortion all that odd)
[19:22] Christine Lemmer-Webber: q+ but very short
[19:23] Jessica: dave: yeah that's the proposal here
[19:23] Jessica: any syrup symbol would now be called a selector
[19:24] Jessica: If we are preceding with the rename can we make it clear in the minutes
[19:24] Baldur: I know of way to do gone_linear kind of gc stuff notification
[19:24] Jessica: and maybe someone can volunteer to update the abstract types document
[19:25] Baldur: abuses a kind of brokenhearts that cause memory pressure than just the object that is being refered
[19:27] Baldur: ya anglophones should get more into wordsmithing! /me shakes staff at cloud
[19:27] Jessica: atom?
[19:27] David Thompson: I prefer sym to selector for the same reason as christine
[19:28] Baldur: quark?
[19:28] Jessica: lol
[19:28] David Thompson: but also don't want this to be a bikeshed thing
[19:28] Kris Kowal: semiotic
[19:28] Jessica: I agree with dave, I'm fine with all the proposed terms
[19:28] Chip Morningstar: hemidemisemiotic
[19:28] David Thompson: we can go to quark's bar after resolving this issue
[19:28] Baldur: garish green for the bikeshed it is
[19:28] Mark Miller: +1 selector, -1 sym
[19:29] Kris Kowal: 0 selector, 0 sym, 0 symbol
[19:29] Baldur: +1 selector
[19:29] Zachary Larson: +sym, +0 selector
[19:29] Christine Lemmer-Webber: +1 sym, 0 selector
[19:29] Jessica: happy with all of them, mild preference for sym
[19:29] Baldur: 0 sym
[19:29] Baldur: -1 atom
[19:29] juli (she/her): +1 sym, -1 selector
[19:30] Jessica: +0 sym, 0 selector
[19:30] David Thompson: +1 sym, -1 selector
[19:30] Baldur: like the sorting callback for Arry.protype.sort()
[19:30] David Thompson: oh I guess -0 for selector sorry
[19:30] juli (she/her): -0 for selector as well, then
[19:30] Zachary Larson: +1 sym; 0 selector; -0 symbol
[19:30] Mark Miller: +0 selector, -0 sym, -1 symbol
[19:31] Baldur: this chat will be copied into the cryptpad afterwards (by me)
[19:31] Mark Miller: -1 atom, -1 quark
[19:31] Jessica: poor quark
[19:32] Kris Kowal: quark got bought by larry ellison this week. tough crowd.
[19:32] Jonathan: +1 selector   (not in chair role)
[19:32] Mark Miller: +1 selector
[19:33] Zachary Larson: +1 sym; +0 selector; -0 symbol
[19:34] Baldur: musing to fix the js issue is to use the well known selector `call`, no?
[19:34] Baldur: or some such selector to that effect
[19:34] Jessica: I also voted +0 sym, 0 selector
[19:34] Jessica: if that matters
[19:35] Richard Gibson: really they're more like gauge bosons than quarks anyway
[19:37] Jessica: I hope yall know what to do with these results lol
[19:37] Erik Marks (MetaMask): I don't know if I qualify as a voting member, but:

-1 sym, +1 selector, -0 symbol
[19:37] Baldur: /me ponders "eindiatal" and refuses to elaborate
[19:37] Jessica: I feel like we overcomplicated this
[19:37] Baldur: same
[19:38] Baldur: I do not care which one
[19:38] Jessica: okay, I guess selector wins
[19:38] Jessica: we have consensus on selector but not on sym
[19:39] Jessica: so I think we should go with selector
[19:39] Erik Marks (MetaMask): I am here
[19:39] Erik Marks (MetaMask): But my my mic is malfunctioning
[19:39] Erik Marks (MetaMask): Christine's interpretation is correct
[19:39] Baldur: this feels like dressing an octupus into eight trunked trousers
[19:40] Baldur: 1/3 of time left.
[19:42] Christine Lemmer-Webber: in absence of a Robert, we will move to another R-based name, either Ryan or Richard
[19:42] Christine Lemmer-Webber: ;)
[19:42] Richard Gibson: roger 🫡
[19:42] Baldur: Ruberto (because been watching Spacemarines 2 streams lately)
[19:42] Jessica: I obviously +1 my proposal
[19:43] David Thompson: but if you know css then selector is confusing ;)
[19:44] Christine Lemmer-Webber: haha
[19:44] Christine Lemmer-Webber: nobody mention CSS!!!
[19:44] Zachary Larson: +
[19:45] Christine Lemmer-Webber: PROPOSAL: That we accept the current OCapN convention of having Selectors (formerly named "Symbols") be a convention corresponding to method invocation, with it still being acceptable to pass selectors outside the first position of an object invocation.
[19:46] Jessica: *is googling roberts rules*
[19:46] juli (she/her): it's quite a thick book iirc
[19:46] Baldur: The Pirates used Roberts expanded by Occupy WallSt
[19:46] Christine Lemmer-Webber: +1
[19:46] Christine Lemmer-Webber: oh ok ;)
[19:46] Jessica: +1
[19:46] Kris Kowal: +1
[19:47] Christine Lemmer-Webber: Jonathan's Rules of Order
[19:47] juli (she/her): +1
[19:47] Mark Miller: +1
[19:47] Chip Morningstar: +1
[19:47] Baldur: +1
[19:48] Jessica: it was just a continuation of last month's meeting
[19:49] Baldur: progress!
[19:49] Jessica: first time we've opened and closed the issue on the same day :)
[19:49] Jessica: I think at least
[19:49] Christine Lemmer-Webber: just placed the order for paint
[19:49] Christine Lemmer-Webber: next month we get to all show up to paint together
[19:49] Jessica: https://github.com/ocapn/ocapn/issues/17
[19:49] Jessica: q+
[19:50] Baldur: I am strongly against IDLs
[19:50] Jessica: me too
[19:50] Christine Lemmer-Webber: MarkM is correct
[19:51] Jessica: correct
[19:51] Christine Lemmer-Webber: q+
[19:51] Baldur: against IDL being a requirement for ocapn but it can be used as docu like typescript jsdoc and such
[19:53] Jessica: +1 to closing the issue
[19:53] Kris Kowal: +1 to closing the issue
[19:53] Baldur: +1 to close the issue
[19:54] Christine Lemmer-Webber: +1 to closing
[19:54] Baldur: OED that uFork which is basically like syrup and cbor and is used by uFork
[19:54] Jessica: q+
[19:54] Christine Lemmer-Webber: MarkM: notably I think that we can't prohibit what we can't prevent, so none of us would suggest *preventing* adding an IDL on top ;)
[19:54] Baldur: ker!
[19:55] Baldur: (which is like vat but in Icelandic ;þ )
[19:57] Richard Gibson: yes
[19:57] Richard Gibson: we can keep going here
[19:57] Christine Lemmer-Webber: does anyone object to "node" given that not all implementations will implement the vat model?
[19:57] Jessica: we need to decide some term
[19:57] Christine Lemmer-Webber: that's what the spec says currently
[19:58] Christine Lemmer-Webber: so it's really "is what the specs say currently ok"
[19:58] Baldur: node is fine by me as it is indicative of the ocapn protocol as other rfcs use that
[19:58] Baldur: host doesnt work
[19:58] Christine Lemmer-Webber: lmao
[19:58] Jessica: +1 to peer
[19:59] Jessica: I like it a lot too
[19:59] Baldur: pierre!
[19:59] Christine Lemmer-Webber: how about pier ;)
[19:59] juli (she/her): omg
[19:59] Baldur: p2p
[19:59] juli (she/her): +1 pier
[19:59] Chip Morningstar: That'll pull in the Docker folks
[19:59] juli (she/her): (also peer)
[19:59] Kris Kowal: but not worf. no star trek.
[19:59] Jessica: I also -1 pier
[19:59] Jessica: funny but not good naming xD
[20:00] Erik Marks (MetaMask): Homonyms are an antipattern, natural language designers take note.
[20:00] Jonathan: peer
[20:00] David Thompson: pear
[20:00] Mark Miller: +1 peer
[20:00] Christine Lemmer-Webber: I'm fine with peer
[20:00] Baldur: pír
[20:00] Christine Lemmer-Webber: pear to pear
[20:00] Zachary Larson: +1 peer
[20:00] Baldur: pi-er
[20:00] David Thompson: peer seems fine
[20:01] Erik Marks (MetaMask): +1 peer
[20:01] Baldur: +1 peer
[20:01] Christine Lemmer-Webber: +0 peer
[20:01] Zachary Larson: (other name come to mind: `agent`... I'm not liking that at the moment; just throwing it out there)
[20:01] Christine Lemmer-Webber: "process" ;)
[20:01] David Thompson: I don't know why node is an issue though
[20:01] kumavis: does spritely have a quay-value store?
[20:01] Baldur: one min over
[20:01] Kris Kowal: hhahahaha
[20:02] David Thompson: okay
[20:02] Christine Lemmer-Webber: netwidget
[20:02] Baldur: boatload of objects!
[20:02] Jessica: I can do it
[20:02] Kris Kowal: but thing specifically is a law registered at a conclave and can’t have any other meaning
[20:02] Kris Kowal: i am an etymological prescriptivist
[20:02] Baldur: we have tackled quite a few this meeting
[20:03] Baldur: winching things forward
[20:03] Zachary Larson: 👏
[20:03] Zachary Larson: 🙌
[20:03] Baldur: got wind in our sails so to speak
[20:04] Erik Marks (MetaMask): I regret but stand by my first contribution
[20:04] Erik Marks (MetaMask): *MetaMask has entered the chat*
[20:04] Erik Marks (MetaMask): I can also do it
[20:05] Erik Marks (MetaMask): Yes
[20:05] Jessica: thanks Erik
[20:05] Jonathan: thanks Erik
[20:05] Erik Marks (MetaMask): Sorry I am unable to speak at the moment, I look forward to doing so at the next meeting.
[20:05] Christine Lemmer-Webber: thank you!
[20:05] Jessica: and thank you Richard for scribing this month
[20:05] Baldur: adjurned!
[20:05] juli (she/her): bye!
[20:05] Christine Lemmer-Webber: bye!
[20:05] Saleh: 🙏
[20:05] Baldur: thx ever1
[20:05] David Thompson: bye
[20:05] Erik Marks (MetaMask): cheers!