01:23 <cquinn> Thanks vaninwagen,

01:26 <cquinn> I am writing an API and want to make sure the caps are friendly for users to pass array literal directly without any extra syntax. I guess box is the most flexible cap for method args.

01:32 <doublec> cquinn: generally you can leave the caps out and just leave it at the defaults in function arguments

01:32 <doublec> cquinn: if you make them box then the function can't modify them

01:38 <cquinn> In my case the args are maps that I will copy the elements out of. Although I guess in some cases I could just keep the original when I won't modify it.

03:38 <cquinn> it would be nice if there was an easy notation for making val literals.

03:41 <cquinn> Another ad hoc capabilities question: should new methods return ephemeral forms of caps? E.g. Array.create(n) should return a ref^ ? Since that is normally the only alias of the new object

03:43 <doublec> cquinn: create is a constructor so it returns the ephermeral type by default

03:45 <doublec> cquinn: it's mentioned here https://tutorial.ponylang.org/capabilities/aliasing.html

03:45 <cquinn> ah, makes sense. I'm just finally grokking the ephemeral forms now. I finally watched George Steed's video from last august and that helped

03:45 <cquinn> ok

16:25 <jordan_> hi folks im a beginner and i am wondering if ponylang has a "std::cin" equivalent of C++ and if so where I can learn more about implementing it

16:33 <jemc> jordan_: as of right now, there does not exist a common interface for input streams, which is something I'd like to change, but it's complicated by the fact that most input stream notifier objects also need stream-specific error handling methods

16:34 <jordan_> @jemc ok thats fine thanks!

16:34 <jemc> for example, a `TCPConnectionNotify` must implement `fun ref received(conn: TCPConnection ref, data: Array[U8] iso)`, but it also has to implement error handling methods like `connect_failed`

16:37 <jemc> cquinn: the pain point you're hitting with array literal caps is one I intend to solve by improving inference

16:38 <jemc> that is, an array literal is a `ref` by default, just because that was determined to be the most likely cap that you want when declaring it

16:38 <jemc> but in cases where you are passing an array literal directly to a method as an argument (or assigning it to a reference with an explicit type), the array literal could/should just use the cap that is expected by the right hand side

16:39 <jemc> (if it is possible, that is)

16:42 <jordan_> i have another pattern-based question: if in actor Main i call a behaviour of an actor A1 (which leads to a series of behaviours of A1_children for.e.g), and then call a behaviour of actor B2, is there a way to pattern to guarantee the behaviour of B2 is executed after all A1 (and its children) have completed?

16:45 <jemc> jordan_: in general, in Pony if you want to have a "happens before" relationship between event X and event Y, you have to create a causal link from X to Y

16:46 <jemc> there's different ways to do it, but one option in your case might be:

16:47 <jordan_> ic, i figured i have to make the link explicit (such as calling B2 from the last terminating A1 child behaviour)

16:47 <jemc> yeah, basically that's what I was going to suggest

16:48 <jemc> there are different ways to accomplish that, and I think it depends on how coupled you want the design of Main to be with A1, and A1 with its children

16:48 <jemc> if you don't mind being coupled, the most straightforward way is to pass Main to A1, and pass A1 to its children

16:50 <jemc> if you don't want the inner parts to be coupled to the outer parts, you could pass a lambda `val` inward that represents "what to do when the task is finished"

16:50 <jemc> or you could potentially use the `promises` package if that suits your use case better

16:51 <jordan_> thanks @jemc i will look into ur suggestions and promises package

17:45 <cquinn> yes, @jemc, that would be a nice addition. Would it help at all if array literals were ref^ (if they aren't already)?

18:02 <jemc> they should be ephemeral already