OCapN Pre-standardization Group

August 2024

Agenda

Minutes

Kris: I've written a tentative agenda, please add to it.

Jar: Let me take a look.

Mark's Annoncements

Mark: After we jointly decided to add mutable bytearrays to OCapN as a basic data type, it's been quite a puzzle to get them into JS. We have figured out a starting point, we've got a disagreement on how to go forward from here in the group. Shim & Ponyfill ? I'll be in the TC39 meeting in Japan to disucss it and propose it, this will be the hard part, from there we should be able to support.

Mark: The bad news is I promised to make progress on what OCapN should standardize on with regard to error objects. I have make progress but not written it down yet.

JAR: So a report for work in progress?

Mark: Yes.

Issue review

Jar: Okay, that's good. We have a thin agenda, does anyone else have other items which are higher priority than issue review. We've had big discussions over the summer. Not hearing any suggestions so maybe we should return to issue review.

Jessica: I've summarized issue 15 which was assigned to me as an AP from last month. I've done this.

Kris: I think even in a month we won't be in a position to have a strong opinion on this. I think we should just leave this open.

JAR: Fine with me too. We're down at issue 15, looking at the newer issues. I might add a comment about the status of it.

JAR: Next is issue 16, this is methods vs. lambda

Christine: I think this is not just about methods vs. lambda, this is something else, it has some alignment with that though. What ian was suggesting was not having an arity of arguments at all, but moving to a single payload which could be any abstract data type (e.g. binary payload, string, etc.) it's up to the implementation to unpack it. This would complicate a number of things, including how promises work. I don't see a strong argument, I don't see any other advicates of this at least.

JAR: Is the issue a statement of the problem.

Christine: It is, I don't know if there's a seperate issue for methods vs. lambda. looks there is. I think this one is related: https://github.com/ocapn/ocapn/issues/54 . At any rate, I think we should close this an open a new issue.

Mark: Point of clarification, if we close this without making any other changes, what's the status quo.

Christine: It'd be not accepting Ian's proposal.

Mark: Given we reject Ian's proposal, it sounds like we don't have a consensus on this.

Kris: I can say what we have is an intersection between what Spritely's and Agoric's prototypes do and this is outside of.

Mark: What's the intersection?

Kris: We should probably open an issue for what is our calling convention, without leaning into a specific solution. We have a number of solution issues, but no problem issue. The major axis of this decision is how broadly do we want OCapN to be expressable in.

Mark: Can you state the intersection?

Kris: I believe what's expressable in JS is having both references to functions and objects, where references can be invoked/called. In Spritely a handler for a call is always a function, conventionally the first argument is a method name, followed by a number of arguments. Is that right Christine?

Christine: We've loosened things where it only returns one argument.

Mark: Lets just make sure I'm following. On the input side it's method name, then some sequence of positional arguments, the result will be a single result.

Christine: In the OCapN spec it doesn't specify this. In the Javascript version this is. You were saying about the method name being false Kris?

Richard: Point of order, I'm interested in understanding the starting state of OCapN and I don't think that's been covered.

Christine: One return value, that we now have across everything. Positional arguments, the convention is there can be a first argument which is a symbol, this would be understood as a method name.

Richard: Just to restart, the inputs are just a list of arguments, where by convention the first element of this list is treated like a method name.

Christine: Right, if a method is being called, yes the convention is the first argument is a method name.

Mark: At agoric we have ? and exceptional completion with an error.

Christine: There's no immediate response so you always get a promise which may be resolved to a error or non-error value.

Kris: We have converged on this from where ?

Kris: On the JS side, a remotable may be a function or an object, the caller decides how to invoke the remote either as a function or as an object with methods. The reciever may only be one or the other, it cannot be both. I don't think we're stuck on this, we can probably conform to whatever is agreed. I believe we can express both function application and method invocation.

Mark: There's something in your explanation about something about False, I didn't follow.

Kris: Yes, When you're invoking a function it's expected to be the scheme false value.

Christine: That's incorrect. Lets say we had a procedure which could accept multiple arguments, e.g. the lisp + function. There would be a false as the first argument, the first argument in (+ 2 3 4) would be 2. There is not a built in idea of methods in either the OCapN spec or Goblins. Everything works like you're invoking a function.

Kris: What that suggestions is that in JS there'd be an equiverlence between calling ??? This would funnel into the same operation in OCapN.

Jessica: I wanted to stress that it's a normal case that there might not be a method.

Christine: If we were seeing more implementations in haskell or ocaml, we'd probably see more implementations similar to how Goblins does it. What does this mean in terms of getting these two world views to align? My memory of this was me and Mark had a call, I had put down a suggestion that since JS doesn't really use symbols, you could easily translate if the first argument is a symbol and dispatch on a method, if there isn't a symbol you dispatch it as a function. I just wanted to clarify the rationale for why it is the way it is.

Mark: Let me make sure I understand how we'd translate this on the JS side. All the method names of concern are strings (or the vast majority), what that would mean is if the OCapN convention was having a flat argument list, we'd have to check the first argument and see if it's a OCapN symbol, we'd translate it into a JS method name (string).

Christine: Exactly right.

Mark: Interesting.

Kris: I just wanted to follow through this thought. If there was only one form on the OCapN layer, that implies that the receiver would have to dmux either as object or as function, this would have to be a choice of the receiver implementation. I think this is possible and servicable. There's a side conversation in chat about if op:get would produce the remote methods.

Mark: JS endpoint for OCapN does not support this.

Kris: Good. I don't think we should support this, nor force this on scheme. If we were going to do the matching on the first argument, it does mean the JS reciever would see a symbol, instead of a string. We still haven't chased symbols to the ground, however I think we've summeraized the issue. How many languages are we thinking will support OCapN? If we embrase ObjC or ML, etc. Protobuf arrived at the convention that is extremely limiting that you'd recieve a struct as the argument and must return a single struct, the reason they did this was it works in a lot of different languages. ObjC does not have ordered arguments, only keyword args, the struct solution allows compatibility of such languages. I think for calling convention, I think we have all agreed that we should leave extreme conventions behind us.

Mark: Christine asked if ObjC is still common? I think it might be in the apple ecosystem.

Richard: Agoric has an important case for string key methods which is the async ? protocol. I don't think we should persue the symbol first argument matching as method dispatch.

Kris: I disagree, we should not expose the async iterator protocol over OCapN. I don't want to impose our general ecosystem to others. It's super chatty and ?. I hope we arrive at a more pipelinable between JS and scheme. I move that we pick between symbol and string for a method name.

Jar: do you want to propose something specific? We can come back to that after the queue.

Mark: I want to agree with Kris, we have very few cases where we use symbols as method names. For each case were we do use symbols as method names, there's probably a good reason to give them up, so I think we could agree on one vs. the other. Lets say a sender tries to invoke a method on a recieving object which is a function not an object, what we'd recieve on the JS side would as the first argument would be a symbol, because of convention. We can obviously accept that but it it'd be weird because it only ever designates a JS string.

Christine: Regarding string vs. symbol as the argument type. We can't do an arity centric approach ? In many functional languages, they're not going to have a concept of a method anyway. I think we can choose string vs. symbol, or we could agree on a world view where you can't mix the two.

Richard: That's very much in alignment, the mixture doesn't work. If we settled on one or the other, it would be possible to send an invocation, on the reciving side we'd know what the right thing to do is (invoke as function vs. method). If we wanted to overload the concept, we'd run into lots of friction. I'm thinking of dynamic dispatch, where you'd want to use a value you recieved in the next argument of the next invocation. We can have a model where it's not an anything goes environment.

Jar: We're close to the end, lets figure out where to leave this issue. Kris you were going to make a motion?

Kris: I defer, we should have a longer discussion.

Jar: A summary of decisions which need to be made would be good. We can also just continue the conversation.

Kris: We could make some proposals which leaves some of the design space behind if that's helpful.

Kris: Do we have any objections to closing the solution in issue 16?

Mark: I second just closing issue 16.

Jar: Any objections to closing issue 16?

nothing

RESOLVED

Kris: I suggest we open an issue for discussing different calling conventions e.g. having seperate operators for invoke & apply or a single operator mediated by a convention.

Christine: Can I suggest Jessica and I open it, we can capture what we discussed here.

Christine: We have no way for scheme or haskell to participate for the other approach, I've had conversations with other folks which said they'd have no idea what they'd do if OCapN had taken the other approach.

Jar: That will be clear in the description of the issue.

Mark: I want to suggest a criteria. The analogy of the round tripping principle we adopted for data. Any invocation which can be emitted, it'd be possible to write a receiver in any endpoint language. Any two invocations which are distinguishable can be distinguished at either endpoint by the receiver which you write in the language.

Kris: Thanks Christine for the clarification that the seperate invoke and apply methods would be difficult in some languages. It does affect my preferences. The IBIS format has been growing in popularity at Agoric, it might be a good format for this conversation. A con would be multiple ops would be difficult to express in haskell/scheme, a con of a single operator for both would be that it'd require in JS that a remotable is implemented with a handler which can be expressed in object or function form, ? entrences that ? can't be GC'd, it'd leave us with a difficult attack vector where messages could blow out the JS heap. The JS symbol would have to be implemented as something which isn't actually symbol, e.g. a tagged object.

Jar: Proposal is Christine and Jessica will compose a new issue about calling conventions. I don't think I need to call for objections.

Kris: With that behind us, more motions! The next is in the "not sure" space. I move that the calling convention would be using either symbols or strings but not both.

Mark: Richard, you raised an objection before, would you like to comment?

Richard: I think we can make it work, especially if we adopt the convention that the first argument is treated as an argument. We could do the mapping. No I don't object.

-- No objections! --

RESOLVED

Kris: I can make another motion...

Kris: I think have agreed to leave objective C out of pool of languages we wish to embrace. Does anyone object?

-- No objections! --

RESOLVED

Jar: Adjourn! We're done.

Next scribe: Richard Gibson

=