Should "dispatch" be extended for timers?

[Michael Doub]

Peter,   Thanks for setting me straight

This means that send with no time specified and dispatch behave exactly the same behavior as a hander or function call, where the currently executing entry is push on to the stack and sent or dispatched item is put on top and is executed.  This makes sense since results are returned to the caller.

if you added a time to dispatch it would not be possible to return a value.   The notion of a stack in any language pushes the current routines context on to the stack, then runs the new routine, and pops the stack to restore the original context and then allow the caller to resume execution.   Data from the called routine is passed back to the caller by modifying the context of the calling routine to point to the returned data.

In the case of the send with a time, the original context of the calling routine is long gone, so there is no way to pass the data back on the stack.   This is why call-back procedures came about.   Data is passed to them in the same way that parameters are passed to a routine.

I still like the idea of adding time as you suggested because of the more clear syntax,  even if we can’t return data is the “with time” case.

-= Mike



On Aug 27, 2014, at 2:59 PM, Peter Haworth <pete at lcsql.com> wrote:

> On Wed, Aug 27, 2014 at 10:42 AM, Michael Doub <mikedoub at gmail.com> wrote:
> 
>> The send with no time specified and dispatch, both inserts the called
>> hander, just below the top entry on the stack to it will be the next to
>> execute when the current top entry is finished.
> 
> 
> I might be misunderstanding your explanation but not sure that's correct,
> at least for dispatch.  Reason I say that is that you can immediately check
> the it variable after a dispatch command to see it was handled or not.
> Plus, if you dispatch a function, you can get hold of the returned value
> in the the result variable in the next line after the dispatch command.  So
> it seems clear the the calling handler waits (or "blocks" in my
> terminology) until the dispatched handler has completed before continuing.
> 
> I think send works the same way if it has no time specified. According to
> the dictionary, a send with no time executes the "sent" handler
> immediately, then execution of the current handler continues.  With a send
> in time, the current handler finishes executing before the "sent" handler
> is started.
> 
> Back to the original suggestion, I still think adding an in time to
> dispatch would be a good idea. I'm just not sure how the ability to use the
> it and result variables after a dispatch with an in time would work.
> 
> Pete
> lcSQL Software <http://www.lcsql.com>
> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
> SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
> _______________________________________________
> 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