00:44 <doublec> aceluck: you need https://is.gd/A29atq

00:44 <doublec> aceluck: that is, you need to explicitly reference the 'y'

00:44 <doublec> aceluck: (in the first closure)

00:45 <aceluck> doublec: Thanks . Yes that's a workaround that works. I'm still of the opinion that this shouldn't be necessary though.

00:45 <doublec> aceluck: I didn't even know you have access to variables in any scope - I thought you had to include them in that extra parameter always.

00:46 <doublec> aceluck: the fact that you can do that does confuse things

00:47 <aceluck> doublec: It'd be more in line with other languages if you didn't need to specify anything that you're using (whether it's nested or not)

00:47 <aceluck> In my code right now, the explicit capture list is 12 variables long and it's starting to look silly

00:49 <aceluck> (blame this book: https://letoverlambda.com)

15:02 <vak> hi all

15:04 <vak> as a newbie I didn't find neither in tutorial, nor in standard library docs nor (most sadly) in examples how to use collections in Pony. Are there any docs/links for a newbie?

15:07 <vak> Having all the variety of trn/iso/ref/box/... I am not quite sure which reference type is the natural one if sender-actor would like to store in a collection its recipients. Maybe I missed an appropriate example though?..

15:10 <vak> and the last question: are there any examples of graph rewriting/transformations using Pony? or at least any example to see what is the natural implementation of the graph in terms of actors?

15:11 <jemc> vak: welcome!

15:12 <jemc> what kind of collections are you looking for?

15:13 <jemc> We have a `collections` package with various mutable collections to read about, and also `collections/persistent` with some immutable/persistent collections

15:13 <vak> jemc: hi, thanks for answering! Most importantly: lists, arrays, dictionaries(or maps) and sets

15:13 <jemc> also, `Array` is in builtin - you don't need to load a package to use `Array`

15:14 <jemc> the `collections` package has `List`, `Map`, `MapIs`, `Set`, and `SetIs`

15:15 <jemc> the distinction between `Map` and `MapIs`, is that `Map` uses structural equality to compare keys (such as the contents of a `String`), while `MapIs` uses identity equality to compare keys

15:16 <jemc> identity equality is particularly useful for objects which are not `Equatable`, or for opaque objects (such as references to another actor)

15:18 <vak> jemc: got it, many thanks

15:18 <jemc> so, for a `Sender` actor that needs to track a set of `Receiver` actors, I'd first reach for a `Set[Receiver]`

15:18 <jemc> err.. sorry

15:18 <jemc> a `SetIs[Receiver]`

15:19 <jemc> about your graph rewriting / transformations question - not sure we have any examples of that, but if you can be more specific about what problem you're trying to solve, I can probably give some useful guidance

15:20 <vak> jemc: I've seen a few occurrences of Array in examples they were all lifted with "recover ... end". I have to read more on Pony to understand why it is so wanted for Arrays to be "iso" in there

15:23 <vak> jemc: Pony looks very, very promising as an actor model oriented language. There are different actor-based approaches for graph algorithms, inspired by Bulk Synchronous Parallel. The Pregel from Google is one to mention

15:26 <vak> if a vertex of the directed graph is a Pony actor and the edges are stored as SetIs collection to its actor-receivers , how could one create an example of such a graph in Pony? it should be probably something like 10 lines

15:30 <jemc> one way to do it would be to make each actor implement a set of behaviours to modify it's receivers, like `be add_receiver(r: Receiver)` and `be remove_receiver(r: Receiver)`

15:31 <jemc> which would be implemented by calling `set` and `unset` on the internally-held `SetIs[Receiver]`

15:31 <jemc> vak: in this case, I think there's no need to lift the set or array to a higher capability, like `iso` or `val`

15:32 <jemc> you make decisions about what rcap (reference capability) to use for a reference based on how you need to us it

15:32 <jemc> *use it

15:33 <vak> jemc: ok, the operations on the graph you are writing about is even cooler than my first simplistic goal to be able to create some dummy static graph like A->B->C->A, for example like this 'looped" triangle :)

15:33 <jemc> in this case, your use case is a mutable set that is held privately within an actor, and never needs to be "sent" in a message across actor boundaries (or, if you ever do need to send this information, you'd want to make a copy, so you could keep your local copy and have it remain mutable)

15:34 <jemc> the requirement about being mutable limits your choices to `iso`, `trn`, and `ref`

15:35 <jemc> if it to be sendable, that would limit your choices to `iso`, `val`, and `tag` - meaning that the intersection of those constraints would force you to choose `iso`

15:35 <vak> jemc: many thanks about your rcap explanations, now I understand more

15:35 <jemc> but this one doesn't need to be sendable, so `ref` is okay

15:36 <jemc> `ref` is usually the most convenient rcap to work with, and should be your default choice for something that you're just working with inside a single actor

15:36 <jemc> especially for a beginner - the uniqueness rules around `iso` and `trn` can be difficult to wrap your head around

15:36 <vak> jemc: my understanding was that if one needs to store an "address" of the receiver-actor, then it should be "tag"... no?

15:37 <vak> jemc: ok, got it.

15:37 <jemc> right - you will hold a `tag` as your reference to each other actor, because that's the only kind of reference you can ever hold to another actor - its address

15:38 <jemc> but you need your `Set` to be mutable if you want to do transformations on the fly

15:38 <jemc> so you will have a `SetIs[Receiver tag] ref` - a mutable set of opaque references

15:39 <vak> jemc: wow. I see :)

16:15 <vak> jemc: wow, it compiles and even runs... :) any comments on this my first stupid piece of code in Pony? https://pastebin.com/hWt7sUhp

16:22 <jemc> vak: you'll run into issues when you try to read the attributes in `EdgeAttributes` - you've created a `get_weight` method on that actor, but you can only call synchronous methods from *inside* the actor - everything exposed to other actors must be exposed as asynchronous behaviours

16:22 <jemc> based on how you're using it (shareable), I'd suggest making `EdgeAttributes` immutable

16:23 <jemc> to do that, rewirte `actor EdgeAttributes` as `class val EdgeAttributes`, and rewrite `new create(weight': F32)` as `new val create(weight': F32)`

16:23 <vak> jemc: thank you! actually it won't be "shared" in the future. Each edge should be rather unique

16:25 <jemc> I'd still suggest `val` is a good place to start

16:27 <jemc> another note is that you don't need to specify `Vertex tag` everywhere - an `actor` type will implicitly use the `tag` capability unless you specify a different one

16:27 <jemc> so you can just say `Vertex`

16:28 <jemc> a `class` type will use `ref` by default, though if you declare it as `class val EdgeAttributes`, you are changing that default to `val`

16:29 <vak> @jemc thank you, updated: https://pastebin.com/Ax9QjC7F