04:56 <endformationage> jemc: Here is a repro of my iso! problem as discussed earlier:

04:56 <endformationage> http://playground.ponylang.org/?gist=1d49e391ba1b80fc30801b9e3d6a4c5f

05:11 <doublec> endformationage: oddly this works https://gist.github.com/384c709daa6c03db55865dbc14b2b2d1

05:11 <doublec> endformationage: seems to be something to do with the anonymous function

05:17 <endformationage> Hmm, interesting.

05:18 <endformationage> Mmm, maybe not, if you uncomment the match, destructive_read_foo matches the iso!

05:19 <endformationage> Which is wierd.

05:19 <doublec> endformationage: this works https://gist.github.com/cd30130bdc9e9e83fb429ebcc47994c7

05:19 <doublec> endformationage: using a local object rather than a closure

05:20 <doublec> endformationage: link to playground http://playground.ponylang.org/?gist=cd30130bdc9e9e83fb429ebcc47994c7

05:23 <doublec> endformationage: I assume it has something to do with the partial application closing over an iso which could result in that iso being aliased multiple times?

05:24 <doublec> endformationage: because bar_make~apply returns a ref, but encloses an iso

05:24 <doublec> endformationage: that ref could be copied, therefore making multiple aliases of the iso

05:25 <doublec> Hmm, maybe not

05:25 <doublec> I don't know really :)

05:25 <endformationage> Ah. Heh. Me neither! :P

05:26 <endformationage> Thanks for finding some solutions though!

05:26 <doublec> Since I can go: let bar_marker2 = bar_maker which seems to me to result in multiple aliases of the iso too

05:26 <endformationage> I can see that.

05:28 <endformationage> But setting aside the construction of the bar, why does this match an iso!, and not iso ?

05:28 <endformationage> http://playground.ponylang.org/?gist=4ff4837a0c371e6b9928b3b86e29dd94

05:36 <doublec> Ah, Although you can have multiple references to the bar_marker, there's still only one reference to the iso because it's a reference to bar_marker not a copy

05:36 <doublec> makes sense now

05:37 <doublec> endformationage: because "Foo iso!" means "whatever can be alias a Foo iso"

05:37 <doublec> endformationage: which is probably equivalent to "Foo tag"

05:37 <endformationage> OK

05:38 <doublec> Anything will match that first statement in the match really

05:38 <endformationage> I switched the match cases and it does match as foo iso first

05:38 <doublec> since "consume destructive_read_foo" is an iso^ which converts to anything

05:39 <endformationage> I had an incorrect understanding of iso!

05:40 <doublec> It's why you see "let x: Foo iso!" and things mainly in generic code

05:40 <doublec> eg. "let x: A iso!"

05:41 <doublec> Since the A type can be any reference capability if the generic code is written that way and you want 'x' to be assignable for anything that can alias it as an iso, etc

05:41 <endformationage> This is very helpful, thanks again. iso is quite tricky.

05:42 <doublec> endformationage: glad I could help. iso is indeed tricky. Especially if you want generic code to work with it.

05:43 <doublec> When iso is involved I tend to use object literals instead of lambda syntax as it helps me reason out what's happening under the covers

05:48 <endformationage> On that note, could you 'expand' the partial application into the object literal so I can see the difference between it and the solution you presented?

05:48 <endformationage> http://playground.ponylang.org/?gist=e92baf524de35327bbacb2ead6654291

05:52 <doublec> endformationage: I'm not sure what you mean, the example I had did have the partial application manually done

05:54 <doublec> I tried this, which doesn't work for the same reason as the lambda version didn't, http://playground.ponylang.org/?gist=41cae82b8e8c0b806bf807f6e165aa24

05:54 <doublec> I don't know why that doesn't work

05:55 <endformationage> I'm still unsure why the lambda version doesn't work.

05:56 <doublec> endformationage: I don't know why either - the object literal version that uses partial application I pasted just before is equivalent and it doesn't work - but I thought it should

05:56 <jemc> I think the partial application is what's causing your issue

05:56 <jemc> (sorry, haven't read the full backlog, so I apologize if that's already established)

05:57 <endformationage> Though I can see why the object literal version does.

05:57 <doublec> jemc: yes, if we manually do the partial application via an object literal it works

05:57 <endformationage> Does partial application change the refcap on the apply back to box, causing the iso to alias?

05:59 <jemc> which paste is the object literal version that works?

05:59 <jemc> from what I see, what you're doing is unsafe

06:00 <jemc> you'd be creating a partially-applied-`bar_maker` that could keep making more copies of the same `Foo iso`

06:00 <doublec> jemc: https://playground.ponylang.org/?gist=cd30130bdc9e9e83fb429ebcc47994c7

06:00 <jemc> that is, the `bar_maker` could be called multiple times, making multiple `Bar`s which all hold the same `Foo iso` (breaking isolation)

06:01 <doublec> jemc: I thought so too but see http://playground.ponylang.org/?gist=5a9da50a52919ef75e1bde9548f6d310

06:01 <jemc> yeah, so the object literal version works because it does a destructive read on the `f` so it can't be used more than once - the partial application doesn't do that, so it's not really equivalent

06:02 <doublec> Right, we discussed that earlier

06:02 <jemc> do you see why the partially-applied-`bar_maker` is unsafe?

06:04 <endformationage> yes

06:08 <endformationage> Thanks again to the both of you. It's difficult to get correct & see the issues involved, but it's great that Pony doesn't let me do the unsafe things I ask it to do.

06:09 <endformationage> Me: Go jump over this cliff. Pony: Nope.

06:36 <endformationage> doublec: jemc: WHoo! Got it working!

06:42 <doublec> endformationage: great!

10:30 <SeanTAllen> Pony 0.19.1 has been released. Includes Lambda and Array inference improvements that have us really excited! https://www.ponylang.org/blog/2017/09/0.19.1-released/

23:19 <Acorn2> Hello again. I recently wrote a paper entitled "A framework for Gradual Memory Management". It proposes a mechanism for supporting multiple memory management strategies within a single program to optimize for performance, with compile-time safety guarantees.

23:20 <Acorn2> The paper heavily borrows from Pony's (and Midori's) reference capabilities as well as Rust's static mechanism for automatic memory management

23:21 <Acorn2> Given that some of its heritage comes from Pony, I thought it might have some passing interesting to some members of the Pony community.

23:23 <Acorn2> If there is any interest, please let me know and I will provide a link in whatever public Pony forum I am told would be the best place for me to use.

23:27 <SeanTAllen> Acorn2: i'd suggest the email list. you can also add it as an item (with description please) to items to be included in our "Last Week in Pony" mailer... https://github.com/ponylang/ponylang.github.io/issues/154

23:41 <Acorn2> SeanTAllen: Thank you. I added it to the github issues. With regard to the e-mail list, which would you recommend I use: user@pony.groups.io?

23:42 <SeanTAllen> I'm not sure what you mean by added it to the github issues Acorn2. I dont see it.

23:42 <SeanTAllen> Did you add it specifically to this issue? https://github.com/ponylang/ponylang.github.io/issues/154

23:42 <SeanTAllen> its not there

23:42 <SeanTAllen> anyplace you added it would be an incorrect place to put it

23:43 <SeanTAllen> please add to issue #154, there's a new issue each week for "Last Week in Pony", that's the issue for items for this week.

23:43 <Acorn2> Ah - my mistake - I am new to Github, I must have create a new issue. My bad. I will try to find it to delete it if I can

23:43 <SeanTAllen> Yes user@pony.groups.io is the mailing list Acorn2. You need to be a member to send to it.

23:43 <Acorn2> Excellent, I will join then

23:43 <SeanTAllen> I close the issue

23:44 <SeanTAllen> go ahead and add to #154

23:45 <Acorn2> done

23:45 <SeanTAllen> aweosme

23:45 <SeanTAllen> thanks