15:45 <SeanTAllen> correct audio now uploaded

18:52 <ro6> I'm just getting started with Pony and really enjoying it. Out of curiosity, is it possible to create a private, actor-local type alias? I have a tuple of U8s and I'm trying to disambiguate them with types so I don't accidentally get the order wrong, similar to what one might do with 'newtype' in Haskell.

18:53 <ro6> Or maybe there's a more idiomatic way to get that safety in Pony...

18:57 <jemc> ro6: we don't have `newtype`-style type aliases yet (https://github.com/ponylang/rfcs/issues/65)

18:58 <jemc> we only have the transitive style of type aliases - that is, if I declare `type A is U8`, `type B is U8`, then `A` and `B` are the same type from the perspective of the type system

19:00 <jemc> regarding "private, actor-local" type declarations - we don't have that concept - we only have "private, package-local" type declarations (accomplished by prefixing with an underscore)

19:01 <ro6> jemc: Gotcha. Thanks for the RFC pointer and the info!

19:01 <jemc> actually, I take it back, you could set up a type-local type declaration using a type parameter

19:02 <jemc> for example, `actor MyActor[A: U8 = U8]` would let you refer to `A` within the declaration of `MyActor` only

19:02 <jemc> right

19:02 <ro6> jemc: And by setting the default the compiler wouldn't require users of the actor to specify the param?

19:02 <ro6> jemc: Would it allow them to override it though?

19:03 <jemc> yes, but only within the constraint you provided (the term after the colon in the type parameter spec)

19:04 <jemc> so in the case of my example, they could specify a type parameter, but it would be constrained by `U8`, so they could only ever specify a `U8`

19:04 <jemc> (since `U8` is a concrete type)

19:05 <jemc> it's somewhat of a weird use of type parameters to do this, but it might suit your purposes

19:05 <ro6> Agreed. I might explore other options, was just hoping for something lightweight. I guess next best would be a class instead of a tuple?

19:06 <ro6> Or an enum with two fields

19:06 <jemc> depending on what exactly you're doing, a class might be more suitable, yes

19:08 <jemc> I still don't think I know enough about what your larger use case is to provide a good recommendation beyond just answering your immediate question about a "private, actor local" type alias

19:09 <jemc> also, I should have mentioned this earlier, but welcome! glad to hear you're enjoying Pony.

19:09 <ro6> Thanks!

19:10 <ro6> I'm actually trying to implement a parallel Game of Life out of actors to familiarize myself.

19:13 <ro6> I have no idea if my planned implementation is correct or fast yet, but I'm just trying to model it in a Pony-ish way. Each cell is represented by an actor that 'ticks' through time steps independently and notifies its neighbor cells about its 'aliveness' at each tick.

19:16 <ro6> Inside each 'Cell' actor I keep track of notifications received from neighbors about their alive state at each tick, so the tuple of (U8, U8) is semantically ("Neighbors I've heard from", "Neighbors alive")

19:19 <jemc> if it's internal state that each actor keeps, why not just keep two fields instead of one tuple field?

19:19 <ro6> It's an array of those tuples

19:20 <ro6> I might just be thinking about the parallel behavior wrong, but since Cells tick independently, I figured some neighbors might be sending notifications of their alive state at future ticks.

19:21 <ro6> I guess I could keep two arrays..., that's just not how it came to my mind.

19:23 <jemc> yeah, two arrays could be one option

19:23 <jemc> what initiates a "tick"?

19:29 <ro6> Once a Cell has received a reference to all 8 of its neighbors it sends them each a notification with it's current tick count and it's alive state. Once this Cell has received a notification from all 8 of its neighbors regarding their alive state for the tick this Cell is on, it ticks forward one step, updates its aliveness, and notifies all its neighbors.

19:31 <ro6> Like I said, this is v1 and I'm still not completely convinced the parallel behavior of this is right, but it seems plausible in my mind...

19:38 <jemc> seems intuitively like the communication between each pairing of neighbors is pretty much synchronous - with the logic of "move to the next tick as soon as all my neighbors have updated for this tick"

19:41 <jemc> seems to imply that you won't get another notification from your neighbor until you've had a chance to acknowledge (and clear) the previous notification from that neighbor (and for all other neighbors in that tick)

19:44 <ro6> I felt similar, just wasn't able to convince myself. I guess that means each neighbor pair can be at most one tick apart

19:45 <ro6> Simplifies things

19:55 <jemc> to test the theory you could always use the `assert` package to check the invariant - that is, at least it would make some noise for you if you ever receive a new notification from a neighbor before an old one is cleared

19:55 <ro6> cool