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

[Tom Glod]

I agree.

i have yet to use the HTML output .... but I would have a hard time meeting
my needs without the wait feature as I use it to keep the UI from ever
being blocked ....which is part of a major feature of the software I am
building.

While I don't  anticipate having this need to output to HTML anytime soon,
if ever, it seems impractical to exclude it for all the reasons you
mentioned.  If we want the HTML engine to be anywhere near as robust and
(precisely controllable) as it is for the desktops, it just has to be there.

On Mon, Jul 31, 2017 at 12:01 PM, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
>
>
> _______________________________________________
> 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
>