<mikeyhew>
As for why tag doesn't work... `{(Foo ref)} tag` can be an argument in the behaviour just fine, but calling `apply` on it isn't allowed, so it's useless
<SeanTAllen>
you said you wanted #send but not tag, which is contradictory.
<SeanTAllen>
"The reference capability of `callback` needs to be `#send` so it can be sent to the actor"
<SeanTAllen>
that includes tag.
<SeanTAllen>
so, you want iso or val.
<SeanTAllen>
correct?
<SeanTAllen>
i'm trying to make sure i understood you.
<SeanTAllen>
and i found your phrasing confusing.
<SeanTAllen>
the reason you would want a function to take an iso is if you need a mutable reference that can be shared with other actors (or come from another actor).
<SeanTAllen>
otherwise val will be fine because anyone who has an iso can turn it into a val.
papey_lap has quit [Ping timeout: 246 seconds]
<SeanTAllen>
unless you want to have a mutable and immutable version but you said "box" as part of that, so i don't think you want immutable and mutable but, i'm not sure i correctly understood what you were communicating.
<mikeyhew>
I say `box` because compiler error messages have told me that function application takes `box`
<mikeyhew>
I think you get what I am saying now
<mikeyhew>
Here's a more involved example, pretty much taken from the cookbook section that I linked: https://is.gd/JOnp4C
<mikeyhew>
In this example, access_val is called, but I'm not sure that every lambda is `val`
<SeanTAllen>
i think we are getting off track
<mikeyhew>
And yes, `iso` and `val` are the only two reference capabilities that work
<SeanTAllen>
why do you want an access_iso ?
<SeanTAllen>
also note, you don't need the consume in access_val
<mikeyhew>
I don't know... I thought there might be cases where a function could be `iso` but not `val`
<SeanTAllen>
see earlier. you don't need access_iso.
<mikeyhew>
I know, I just wanted to be consistent, because ideally access_iso and access_val would be combined into a single, generic, access function
<SeanTAllen>
im not sure what you mean by "consistent"
<SeanTAllen>
val and iso are two very different things
<SeanTAllen>
the iso one says "i need to be the only thing that has an alias to this"
<SeanTAllen>
the val one says "i need to have access to an immutable version of this"
<SeanTAllen>
those two things are combinable
<SeanTAllen>
arent combinable
<SeanTAllen>
i'm not sure you have a good grasp on what iso is useful for at the moment as a parameter. i have a bit of time and we could discuss it more if you want to. let me know if you are interested in doing that.
<mikeyhew>
maybe I don't. I thought the point of `iso` was so you could send something to an actor and allow that actor to do whatever it wants with it, knowing that no other actors are reading or writing to it
<SeanTAllen>
sort of.
<SeanTAllen>
the part you are missing is that you need it to be mutable.
<mikeyhew>
right
<SeanTAllen>
so the question with your access is, do you need mutable access to the parameter?
<SeanTAllen>
if you don't then you don't need iso.
<SeanTAllen>
you only need val.
<mikeyhew>
right
<SeanTAllen>
and if someone has an iso, they an turn it into a val if they want.
<SeanTAllen>
so you dont need access_val and access_iso
<mikeyhew>
that part isn't so obvious to me
<SeanTAllen>
which part?
<mikeyhew>
that you can turn an iso into a val
<SeanTAllen>
val/iso on a parameter isnt about what the caller has, its about what they have to supply
<SeanTAllen>
iso is a thing with a single alias to it correct?
<SeanTAllen>
if i consume that alias, iso ^, then its safe to assign to any other reference type
<SeanTAllen>
i can assign to `val` and it is now immutable.
<mikeyhew>
But now it's immutable...
<SeanTAllen>
right
<SeanTAllen>
whats the problem with that though?
<SeanTAllen>
if i only need immutable access to it
<SeanTAllen>
why does it matter if its mutable or immutable?
<SeanTAllen>
and you have to give up your alias to the iso anyway
<SeanTAllen>
the point isnt that its mutable or immutable, its that a consumed iso can become anything you want it to be
<SeanTAllen>
i can consume an iso and assigne to a `ref`
<SeanTAllen>
now its mutable and there can be many aliases
<SeanTAllen>
and that is also safe
<SeanTAllen>
the important point of this is... its not about what the caller has, its about what guarantees about the parameters that this function/class needs
<mikeyhew>
Who says you only need immutable access to it?
<mikeyhew>
Can you call a function if you only have immutable access to it?
<SeanTAllen>
i dont understand either question. sorry. let's start with the first one.
<SeanTAllen>
what do you mean "Who says you only need immutable access to it?"
<mikeyhew>
I ask because I'm used to Rust, where there's FnMut closures that mutate their environment
<SeanTAllen>
ah so
<SeanTAllen>
you are talking about a closure, not parameters in general?
<mikeyhew>
Yes. access' parameter is a closure
<SeanTAllen>
right but it wasnt' clear to me at this point that in your simplified example you were concerned with specifically with the closure nature of it.
<SeanTAllen>
as it started with "Is there a way to be generic over `iso` and `val`?"
<mikeyhew>
Oh. Sorry for the confusion
<SeanTAllen>
it all makes a lot more sense now.
<SeanTAllen>
so
<SeanTAllen>
assuming this closure is mutable and i send it to another actor
<SeanTAllen>
like your access one
<SeanTAllen>
you as the writer of access would know have the only alias to this closure, correct?
<mikeyhew>
yes
<SeanTAllen>
ok
<SeanTAllen>
so
<SeanTAllen>
even if it mutates it environment
<SeanTAllen>
thats probably the end of the line
<SeanTAllen>
unless its mutating its environment and doing some call based on it
<SeanTAllen>
i suppose you could wrap something rather complex up in that
<SeanTAllen>
but then, there is no way to make that generic over the two
<SeanTAllen>
if i understand what you mean by that
<SeanTAllen>
unless, you mean something like this...
<mikeyhew>
That example is pretty much what I mean
<mikeyhew>
Is there a way to combine access_iso and access_val into a single generic function?
<mikeyhew>
that supports both iso and val?
<mikeyhew>
On another note, I'm having trouble creating a closure that is `iso`
<SeanTAllen>
what have you tried?
<mikeyhew>
I think I got it. You have to add `iso` at the end
<SeanTAllen>
this is definitely something i want to bring up at a sync meeting. thanks for walking me through it mikeyhew.
<SeanTAllen>
"it" being iso/val and closures that can be send around.
<SeanTAllen>
i need to play around with it more.
<mikeyhew>
I'm glad to hear you've found this helpful!
<mikeyhew>
Can you take a look at this? I think it says that creating an `iso` closure inside of `create` makes the Main actor no longer sendable https://is.gd/LYlizu
<mikeyhew>
Or maybe that's not it
<aceluck>
mikeyhew: Put iso between new and create in the Mutable class to get further at least
<mikeyhew>
Is there a way to tell the closure to consume mutable?
<mikeyhew>
aceluck: thanks
<SeanTAllen>
mikeyhew: and then you will have a different problem
<SeanTAllen>
your class iso Mutable
<SeanTAllen>
you really meant
<SeanTAllen>
new iso create()
<SeanTAllen>
i believe
<SeanTAllen>
"the default type for this when created should be default"
<aceluck>
Is there any editor or tool that will pretty print / reformat pony code?
<Praetonus>
aceluck: Not currently. We'd like to eventually expose the compiler APIs as a library to parse (and compile) Pony code so that such tools are easier to write
carado has left #ponylang ["WeeChat 1.7.1"]
<aceluck>
I noticed you already export the grammar, which is very nice
<aceluck>
I don't seem to be able to capture variables in nested closures..?
Praetonus has quit [Quit: Leaving]
<SeanTAllen>
can you give a small example snippet of code that isnt working for you aceluck?
<SeanTAllen>
So you are expecting y to be in scope 2 nested levels down?
<aceluck>
If it's a closure in the lisp sense, it should capture its environment lexically.
<aceluck>
I think what's going on is that the first closure doesn't capture y, it only captures x, because y is not used.
<aceluck>
Thus it's not in scope for the inner one.
<aceluck>
But if you're translating functional code (like I am right now), this is problematic. It can easily be worked around though, by explicitly mentioning the capture, but it's an extra hassle.
<SeanTAllen>
yes
<SeanTAllen>
if you think it should be different, i'd suggest opening an RFC for discussion.
<SeanTAllen>
and cover things such as, should it be capturing fields?
<SeanTAllen>
the Pony approach is you only capture variables that are referenced.
<SeanTAllen>
you do not capture every variable.
<aceluck>
Yes I see that.
<SeanTAllen>
another issues the RFC would have to address is
<aceluck>
However, y is referenced in this case
<SeanTAllen>
i dont see how it is referenced
<aceluck>
It's just that it's referenced inside a closure, and the compiler doesn't see that
<aceluck>
This line "Bar" + y references y
<SeanTAllen>
perhaps i wasnt clear
<SeanTAllen>
the first closure doesnt capture y because it isnt used
<SeanTAllen>
therefore there is nothing called y available to the next
<aceluck>
But the second closure is inside the first one right, so it is used
<SeanTAllen>
this is how pony operates
<SeanTAllen>
im trying to explain the pony approach
<SeanTAllen>
so you could make an argument for something different
<aceluck>
I understand what you're saying
<SeanTAllen>
i understand the code you wrote
<SeanTAllen>
ok
<SeanTAllen>
well then
<SeanTAllen>
if you want to open an RFC to suggest a change you can
<SeanTAllen>
but there's a lot of particulars you will need to cover about how capture rules work
<aceluck>
But the inner closure is inside the first, so I'd argue that it has to consider that when deciding what's referenced or not
<aceluck>
I'm not saying this needs to change, but I do suggest it is discussed at least. Anyone with lisp, haskell or similar background would be expecting lexical closure
<aceluck>
Thanks
<SeanTAllen>
Given the definiton in the tutorial, you could also argue that this is a bug
<SeanTAllen>
So if you want, you can open an issue first to discuss.