alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
endformationage has quit [Quit: WeeChat 1.9.1]
_whitelogger has joined #ponylang
bb010g has joined #ponylang
<bb010g>
Ok, so I ran into an aliasing problem and the only solution I could find that compiles feels brain-dead: https://wank.party/6bGI.txt
<bb010g>
Are there any better ways to do this?
matthias_wahl has joined #ponylang
<vaninwagen>
I think if you want to return A from your iterator object, you need to pass it an Iterator[A^]
<vaninwagen>
In some minutes i will be able to play with your example a bit
<vaninwagen>
And yeah, you need the consume
<Candle>
oooh! not seen this error class before: "identifier 'foo' is consumed when the loop exits"
<matthias_wahl>
bb010g: the thing about your example is that it won't work for iso, unfortunately, because the _value is always kept as a field and an alias is handed out
<bb010g>
Really? I got alias errors there when I didn't consume and directly closed over the argument, but nothing when it was consumed into the class variable
<bb010g>
vaninwagen: Which consume are you referring to?
<bb010g>
What I don't quite get is why the alias on the return type is necessary at all, given that the one variable holding isn't ever accessed until the consume at the end.
<bb010g>
The tuple sequencing trick seems to convey that to the compiler, but I thought that consume's job was to allow you to say when you aren't using an alias anymore.
<matthias_wahl>
which variable holding are you referring to? to _value?
<matthias_wahl>
the one, you intersperse?
<bb010g>
To the result of the _iter.next()? call that I want to assign for a bit to n
<Candle>
matthias_wahl's playground has next() returning a A! rather than an A; which, I think means that you have to return the result of a consume.
<matthias_wahl>
the alias is necessary, because the inner iterator is only handing out A, not A^. That actually means, you only get an alias out of it
<bb010g>
But if I don't store it anywhere and directly return, I can get an A out, right?
<matthias_wahl>
i admit what the compiler does here is a bit confusing.
<bb010g>
This felt like a situation where recover should help, but you can't say `recover #any^ foo end`
<malthe>
wrt recover expressions, if pony was to adopt non-lexical scoping, couldn't they be made to work like consume?
<malthe>
(similar to how rust has moved to NLL).
<bb010g>
recover would just give the same type
<matthias_wahl>
bb010g: if you don't store it anywhere yes
<bb010g>
So, there is no way right now to store any value in a variable, not touch it, and then pull it back out as it was?
<matthias_wahl>
bb010g: consume is the way
<Candle>
Once you store an object in a variable, you potentially create another alias to that object.
<matthias_wahl>
bb010g: if you store it in a field, you need to use a destructive read to assign a new value and get the old back
<bb010g>
Ok, and consume is the variant of that doesn't immediately require assignment, right?
<bb010g>
The issue here I think is that I couldn't get my arbitrary value stored with its original type at all in the first place. consume or destructive reading would probably work here if I had the right type to work with
<matthias_wahl>
the reason why the consume did not compile in the first place, was because of the inner Iterator, returning an A
<matthias_wahl>
so, it is an in-flight A (e.g. String iso), when you assign it to something, you create an alias to it, it becomes an A! (String iso!)
<matthias_wahl>
so your n was never an A, but a A! in the first place
<matthias_wahl>
the inner iter should be an Iterator[A^] (returning ephemeral types, which when aliased become the base capability (e.g. String iso^ becomes String iso when aliased)
<bb010g>
So, why does my tuple version compile? Is it a soundness error?
<bb010g>
This all seems extremely dependent on whether I'm assigning in the body
<matthias_wahl>
bb010g: i am thinking about it
<bb010g>
Actually, I wonder if I could store the temp as a tag. Don't know why I didn't try that before
<matthias_wahl>
you won't get a higher capability back then
<bb010g>
Nope, I'm dumb, also recover doesn't like the _iter ref method call
<bb010g>
knew that already
<matthias_wahl>
shit, this really is a soundness error
<matthias_wahl>
bb010g: you wanna create an issue ticket or should I?
<bb010g>
I can do it in a few minutes
<bb010g>
Gotta love discovering new soundness errors in your first week
<matthias_wahl>
bb010g: that's a pretty good start!
<matthias_wahl>
second week is for fixing :P
<bb010g>
I also want to just go in and try to beat tuples into submission so I can stop freaking out whenever one gets kinda close to a union
<bb010g>
And some code of mine could be cleaned up from that working properly
<malthe>
like recover iso ... super long expression as in the example on the homepage ... s end - to me this is spooky action at a distance
<matthias_wahl>
spooky indeed, and a little late for halloween
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
alxs has joined #ponylang
alxs has quit [Client Quit]
alxs has joined #ponylang
alxs has quit [Quit: Computer's gone to sleep. ZZZzzz…]
matthias_wahl has quit [Quit: WeeChat 2.3]
<vaninwagen>
bb010g: i talked to plietar about the issue i thought to be a soundness problem - we (or more correctly he) came to the conclusion that it is actually safe
jemc has joined #ponylang
jemc has quit [Ping timeout: 260 seconds]
endformationage has joined #ponylang
<bb010g>
vaninwagen: Oh, ok. How is this safe, then?
<vaninwagen>
bb010g: you actually have the reference _value at hand in the example and you cannot do unsafe stuff with it. You cannot create another mutable alias
<vaninwagen>
It is a bit tricky to follow, but it is actually the same reference, through auto-recovery
<vaninwagen>
And it only works if all args to the iso value are themselves sendable
<vaninwagen>
So i couldnt call append on it with a ref value for example, and introduce a leaking reference to the iso object-tree
<vaninwagen>
And also i think you can't consume it and send it somewhere
<bb010g>
Ok, this matches to work what I was thinking
<bb010g>
Any reason that auto-recovery works on the next_value() return, but explicit recovery seemes to do nothing?
<bb010g>
My question is whether doing that tuple construction and access to sequence the second set of things with guaranteed no access to the first value and type is the only way to push out a value of any type without modification while still doing unrelated stuff with other values after
<vaninwagen>
Afaik it shouldnt be
<vaninwagen>
Assigning to a local let, then doing the second thing, then consuming the local let should work fine
<vaninwagen>
I think the issue in your case is that assigning the result of the inner iter to a variable stops auto-recovery from working transitively
<vaninwagen>
So your trick actually avoids another alias, which seems to be required
<vaninwagen>
What puzzles me is that auto-recovery does sth.that manual recovery is not able to, it seems