Receiver capabilities of constructors not documented

[non-Jedi]

• Meaning of e.g. new ref create() should be explained.
• It was mentioned on irc that new val create() would only accept sendable arguments. This should also be documented.
• I assume that fun val foo() would also only accept sendable arguments. I don't think this is documented either.
• Probably should add further explanation of default reference capability for a type and how it differs from using a constructor with a certain receiver capability.

[jemc]

I assume that fun val foo() would also only accept sendable arguments. I don't think this is documented either.

Actually, this one isn't a requirement. The reason we have that requirement for new val create is because it's roughly equivalent to a recover statement - the fields of the constructor are mutable inside the constructor body, but once it returns, the object is lifted to val. We have to require sendable arguments there for the same reason a recover statement can only allow sendable references from outside the block to be used inside the block - because otherwise a non-sendable could get embedded in the recovered sendable object, breaking capability safety.

For fun val this is not a problem because the receiver is treated as val inside the method body, so you can't assign anything to it or do anything else that break capabilities.

[SeanTAllen]

Thoughts on where this would go @jemc?

[shelby3]

It was mentioned on irc that new val create() would only accept sendable arguments. This should also be documented.

The reason we have that requirement for new val create is because it's roughly equivalent to a recover statement - the fields of the constructor are mutable inside the constructor body, but once it returns, the object is lifted to val.

Assuming class fields can’t be assigned from in a constructor (and noting that assigning from sendable arguments to non-sendable arguments is illegal), then I presume one of the reasons for not making an exception for constructor arguments which are only assigned to instead of assigned from, is because constructors really shouldn’t be encouraged to have side-effects? If so, then for consistency shouldn’t constructors (of all capability types) be forced to never assign to input arguments (or at least those which aren’t assigned from)?

I contemplated whether Pony has a feature to enforce referential transparency orthogonal to necessary degrees-of-freedom for reference capabilities. I pondered whether a function that takes mutable reference capabilities could possibly be referentially transparent. Contemplated whether conflating reference capabilities and referential transparency invariants would reduce degrees-of-freedom. Although a function which leaks a mutable reference capability in its return value is I guess not referentially transparent because the return value can mutate. Thus I guess box, val and tag arguments do cover the referentially transparent cases.

[jemc]

@SeanTAllen - I'm not sure the best place to put this, to be honest. We introduce methods and the idea of fun ref very early in the tutorial before we talk about reference capabilities at all, and we never really come back to talking about how receiver capabilities work in detail, for either for fun or new.

We probably need to add a new page to the "Reference Capabilities" section called "Receiver Capabilities" we talk about how receiver capabilities work in detail, for both fun and new.

[rhagenson]

Great issue! Closest mention of receivers is in viewpoint adaptation: tutorial.ponylang.io/reference-capabilities/arrow-types.html I think this needs to be after the introduction of refcaps and before viewpoint adaptation so perhaps around "Passing and Sharing References" is a good fit? Start with (re)emphasis that anything which can be assigned to a variable has a refcap and therefore when calling methods there is an implied access to the receiver -- then this would allow discussion of constructors without seeming out of place by stating the constructor sets the capabilities of the receiver. I recall a conversation on Zulip about this being undocumented. (Will need to snag the link later). That might help steer how people think about this idea before they know how it is really done.

…

On Mon, Jun 15, 2020, 11:51 AM Joe Eli McIlvain ***@***.***> wrote: @SeanTAllen <https://github.com/SeanTAllen> - I'm not sure the best place to put this, to be honest. We introduce methods and the idea of fun ref very early in the tutorial before we talk about reference capabilities at all, and we never really come back to talking about how receiver capabilities work in detail, for either for fun or new. We probably need to add a new page to the "reference capabilities" section called "receiver capabilities" we talk about how receiver capabilities work in detail, for both fun and new. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#212 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJJ6P74TN6AYMYHYUJXSI3RWZGSXANCNFSM4DU27PLQ> .

[SeanTAllen]

Adding a sub-point that isn't in the checklist above: the receiver capability of this inside a constructor body.

Until every field is assigned, this is tag. So you can't pass this where a ref (or box/val) is wanted until the last field is set. It's most surprising for classes, since a class instance is ref everywhere else; for actors this is tag from the outside anyway.

class Bar
  new create(f: Foo ref) => None

class Foo
  let _env: Env
  var _n: U32
  new create(env: Env) =>
    _env = env
    Bar(this)   // won't compile: `this` is `Foo tag` until _n is assigned
    _n = 0

The compiler reports the argument type as Foo tag. Move the call below the last field assignment, or give the fields default initializers, and it compiles.

This trips people up, and a cursory look through the tutorial didn't turn it up. I'm not sure where it belongs (here under constructor receiver caps, or next to field initialization), but we should cover it.