Wait, the problem, and why it is important to solve

[Mark Waddingham]

Indeed - we can make all the things on the list I made have a callback / without waiting form too.

In terms of wait itself - it is the HyperTalk way of doing 'async' - allowing you to write such code without the 'headache' of nested callbacks / closures and such - this is why it is important to retain and improve. It makes coding event driven things easier.

The fact that C# has async, and JS is getting it (because node.js primarily) shows that it is an important pattern. One we've had for years, just in a restricted (recursive) form.

Warmest Regards,

Mark.

Sent from my iPhone

> On 31 Jul 2017, at 16:39, Mark Wieder via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
>> On 07/29/2017 09:23 PM, Mark Waddingham via use-livecode wrote:
>> 
>> P.S. One other possibility I've toyed with is doing LCS->BYTECODE, then BYTECODE->ASYNCIFIED_JAVASCRIPT. The latter would be particularly easy if targetting browsers which have already implemented the new async JavaScript features. Since it looks like the HTML5 engine will only become truly widely usable when we move to WASM, this might well be a much more maintainable, and relatively quicker option.
> 
> I also want to point out (thanks for that long well-thought-out post) that many of the use cases you list might be better served with callback functions than with a cobbled-together 'wait' command. Javascript on its own doesn't have a wait or sleep command, and while there are ways to simulate the effect, they are problematic in a real-world environment where network timing issues are out of control of the calling code.
> 
> -- 
> Mark Wieder
> ahsoftware at gmail.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode