4 ms·

Append style programming is very interesting, especially when thinking of modelling future languages closer to natural language. This foray though seems to end

Append style programming is very interesting, especially when thinking of modelling future languages closer to natural language. This foray though seems to end up generating more problems than it's worth. For one, its not clear how this aids easier development - hasn't it just shifted understanding of a complex program to understanding a complex overlapping sequence of b threads instead? Secondly, and I think the nail in the coffin, the compiler would have to be brilliant at optimisation to make the final program performant. The idea of 'show ads' later being disabled by another overlapping b thread - does this mean the network request is never performed? Or is it performed and the result thrown away, wasting resources. How would an 'offline mode' requirement be appended as a b thread in such a case?

codebje 7y ago
The events are a scheduling mechanism, not the work done. Performance probably relates more to the ratio of time spent selecting the next event to time spent executing code between yields than anything else: a thread waiting on an event joins a queue, a thread requesting an event joins the same queue but also flags it as ready, and a thread blocking an event flags the queue as not ready. When a queue is selected, it's drained completely before a new queue is selected. The run cost of the scheduler would depend mostly on the structure used to maintain the ready set, but a basic double ended linked list would provide linear time operations for ready/blocked management. Whole program compilation could provide lookups or perfect hashes for event queueing, or partial compilation could rely on imperfect hashing. Optimising during compilation might work best by trying to fuse events such that the scheduler is invoked less often. Things that are not apparent from a lightweight article like this include state transfer (how do I know details of the card inserted?) and the likelihood that I'd keep the code to each b-thread and hack on those to make new ones...

codebje 7y ago

The events are a scheduling mechanism, not the work done. Performance probably relates more to the ratio of time spent selecting the next event to time spent executing code between yields than anything else: a thread waiting on an event joins a queue, a thread requesting an event joins the same queue but also flags it as ready, and a thread blocking an event flags the queue as not ready. When a queue is selected, it's drained completely before a new queue is selected. The run cost of the scheduler would depend mostly on the structure used to maintain the ready set, but a basic double ended linked list would provide linear time operations for ready/blocked management. Whole program compilation could provide lookups or perfect hashes for event queueing, or partial compilation could rely on imperfect hashing. Optimising during compilation might work best by trying to fuse events such that the scheduler is invoked less often. Things that are not apparent from a lightweight article like this include state transfer (how do I know details of the card inserted?) and the likelihood that I'd keep the code to each b-thread and hack on those to make new ones...