<malthe>
In "ip_endpoint.pony:32:9": lambda(IPAddress): String end val is not a subtype of Fulfill[IPAddress val, String val] iso: val is not a subtype of iso
<malthe>
I'm trying to experiment with a "net" package that's based on promises when applicable. For example, a `TCPListener` might be able to bind to a port, but it also might not which seems to be better suited for a promises-based API than using the notifier pattern.
<jemc>
malthe: this is one of the usability issues with lambdas that I want to resolve - the compiler sets the type of the lambda based only on the lambda itself, with no inferring based on the type that is expected for assignment or argument passing
<jemc>
the solution is to surround your lambda in a recover block
<malthe>
I tried that to no avail
<malthe>
same error message. sometimes I just can't wrap my head around what I'm supposed to do, but generally speaking, once you arrive at a solution it becomes clear.
<malthe>
jemc: oh, actually I think recover iso does work.
<malthe>
thx
TonyLo has quit [Ping timeout: 264 seconds]
<malthe>
jemc: so the only way I can make it work is to add an arbitrary (and unused) capture to the lambda - see updated gist.
<malthe>
isn't that bizarre? how does that change anything
<malthe>
if I leave out the capture and recover explicitly to iso, then I get "can't recover to this capability".
<jemc>
this happens because a lambda with no captures is implemented as an anonymous primitive, and a lambda with captures is implemented as an anonymous class (same as an object literal)
<jemc>
it's definitely a usability issue that the compiler can't make this work automatically for you
bitcrusher has joined #ponylang
<malthe>
right. where to begin looking at improving that I wonder
<jemc>
it needs to be fixed in the compiler passes - I've spent time working on this before, but the way the passes currently work it's rather difficult to get it done in the right place
<malthe>
is it because the Fulfill is "interface iso" that it insists on the iso and not e.g. val
<jemc>
I had previously been thinking of this as a case where we want to auto-recover the lambda, but your example actually shows that this isn't true, as a `val` constructor can't be recovered to `iso`
TonyLo has joined #ponylang
<malthe>
ya that would break expectations :-)
<jemc>
I usually hit this problem going in the other direction - I have an `ref` lambda (with captures) that I need to pass where an `iso` or `val` is expected, and recover works fine for that
<malthe>
what's something that's either an iso or a val
<jemc>
but your example is a great reason to think that this is a deeper problem that is more specific to lambda
<jemc>
malthe: I didn't mean the same situation accepts an `iso` or `val` - I meant different situations, some expecting `val` and some expecting `iso`
<malthe>
ya but so the promises interface wants an iso fulfill object, but couldn't you argue that it could accept a val just as well?
<malthe>
both of those can be sent to the promise actor ... isn't that the requirement here?
_whitelogger has joined #ponylang
_whitelogger_ has quit [Remote host closed the connection]
irx[m] has quit [Quit: node-irc says goodbye]
notwas has quit [Ping timeout: 240 seconds]
<malthe>
I posted the question on the dev list to see if it might be possible to adapt the promises implementation so that it might actually also accept a val fullfill/rejected.
TonyLo has quit []
<jemc>
I think it probably could be, though it would complicate the codebase
<jemc>
I see this as a general problem with lambda usability, rather than a specific problem with the promises package
Matthias247 has quit [Read error: Connection reset by peer]