Repository navigation
“Automatic Receiver Recovery” section is incorrect or confusing? #321
Description
https://tutorial.ponylang.org/capabilities/recovering-capabilities.html#automatic-receiver-recovery
[…] and that means we can call
refmethods on anisoortrn, sinceisoandtrnare both subtypes ofref.
If all the arguments to the method at the call-site are sendable […]
For example, if the method being called wants a
refargument, and we pass it anisoargument, that's sendable at the call-site, so we can still do automatic receiver recovery.
The section seems to imply that all (including the receiver) the arguments must be sendable, but a trn is never sendable. Since the receiver is being recovered, I am thinking it doesn’t need to be sendable. Or if I am incorrect, then how can this work for trn?
Note I have never run the Pony compiler in my life. I just started learning by reading the tutorial over the past couple of days. So apologies in advance if this issue is invalid. I don’t have time to sign-up for the mailing list to ask first.
Activity
jemc commentedon Oct 11, 2018
While the receiver may be thought of as an argument to a function (if you're thinking about how functions are isomorphic to methods), that's not what it means here - we mean the phrase "arguments to the method" to be taken literally.
If you take that isomorphic thought to its logical conclusion, automatic recovery could be done on at most one non-sendable argument instead of a non-sendable receiver, but Pony doesn't implement that yet.
shelby3 commentedon Dec 3, 2018
I appreciate your clarification.
Indeed I was thinking of the most general model.
The receiver is an argument to the method. One thing I have learned from those in the functional programming community such as Haskell, is that a method is nothing more special than a function which associates one of its arguments with the (possibly implicit)
this.¹So I still think the documentation is slightly misleading on that point for someone coming from a mindset of functional programming. I see no reason not to improve it.
One of the great things about open source is we get the opportunity to reward others for contributing by accepting improvements, unless their contributions are simply wrong.
¹ Additionally when we end up adding the superior paradigm of typeclasses (and discarding that paradigm of premature binding of interfaces/traits to data instances) so that we can add new interfaces to existing data, then the distinction of a method is just inconsistent and arbitrary. Modules (aka packages in Pony) can be used for encapsulation instead.
jemc commentedon Dec 3, 2018
If you have a suggested wording here that will make things clearer to our readers, we're open to suggestions. You can reopen this if you want. I only closed it because I considered the matter to be settled, but that's open to interpretation.
shelby3 commentedon Dec 5, 2018
The inconsistency in that section is:
That literally states that the receiver must be sendable. The reader may be able to deduce that you excluded receiver from the second quoted statement, but I suggest it would be better to state so explicitly.
Other than rewriting the section extensively which is probably not necessary, my suggestion is:
By stating “other than the argument being recovered”, that will establish a compatible understanding for any future case where Pony enables annotating which argument of functions should be automatically recovered. Which is a point I am going to eventually broach on the mailing list in the broader context of free functions and type classes.
If I don’t have an error in my understanding, I would appreciate if someone will reopen if they think it is worthwhile. I will not reopen now because I don’t yet have enough confidence in my understanding of Pony. Maybe I will return this later if no one reopens.
Update section on auto-recovery to clarify that receiver need not be …
Update section on auto-recovery to clarify that receiver need not be …