Re: Promises in Pike vs other languages

On Wed, May 25, 2016 at 10:30 PM, Per Hedbor () @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>I think the biggest benefit is that your async programming becomes/or >>looks more sequential/synchroneous which tend to be easier to follow, >>or in other words less spaghetti-ish. >

Re: Promises in Pike vs other languages

Well, yes, but the need for ; (or }, or some other definite end marker) to terminate the top level expression applies to explicit lambda expressions as well. Although less likely to appear in actual code mixed q = lambda(){}-x; is also syntactically valid (x would need to be an object with a

Re: Promises in Pike vs other languages

Well. I mean the fact that you have to have a ; after } where } define a function in functions (well, that's not really why, but it's where it shows up).

Re: Promises in Pike vs other languages

>Your example did not contain any definitions of functions in >functions. That's sort of debatable, since x(){} is just a shorthand syntax for x(lambda(){});, which does define a local function. :) I do see the conflict, however.

Re: Promises in Pike vs other languages

>Also: Could we get rid of the trailing ';' somehow in the grammar? You mean have an implicit ; before end braces, like this: int main() { write("Hello, world!\n"); return 0 } ? Probably possible, but I don't know if it's a good idea...

Re: Promises in Pike vs other languages

>From looking at the module, that was far from obvious if you ask me. Even though the docs says just that. I'm not sure I see how having separate methods here will give us better typing, but maybe it does. My opinion is that we should try to have an API that is as similar as possible to others

Re: Promises in Pike vs other languages

>I think the biggest benefit is that your async programming becomes/or >looks more sequential/synchroneous which tend to be easier to follow, >or in other words less spaghetti-ish. And I definitely beg to differ that. Take this future-less code from a chat server: | void

write callbacks and Stdio.File.set_buffer_mode()

Yes. Inherit the buffer, then implement a function bool range_error( int bytes ) { if( more data added to buffer ) return true; return false; }

Re: Promises in Pike vs other languages

> 25 maj 2016 kl. 09:05 skrev Martin Karlgren : > > Future f = do_async_stuff(); > f->flat_map (lambda (string result) { return > do_more_async_stuff_returning_a_future(result); })->on_success (lambda > (string final_result) { }); > f->map (lambda (string result) { return

Re: Promises in Pike vs other languages

Regarding chaining – I think you’re looking for Future.map and Future.flat_map. Calling map in a Future will return a new Future that will be fulfilled with the result of the callback provided to map. flat_map allows the callback to return a new Future, which will be chained with the Future

Re: Promises in Pike vs other languages

> 24 maj 2016 kl. 17:25 skrev Per Hedbor () @ Pike (-) developers forum > <10...@lyskom.lysator.liu.se>: > > […] > Also, I personally belong to the "future/promises don't really add much" > camp, but feel free to add the API. :) > > (In my opinion it's just another way to complicate

Re: Promises in Pike vs other languages

> 22 maj 2016 kl. 16:40 skrev Marcus Agehall (nu med K-märkt fastighet och ny > elcentral) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se>: > > I have spent some time looking at the new stuff in Concurrent.pmod > that Grubba has added to 8.1. Mostly it is code relating to the > concept