Thoughts on JS library to help with event driven paradigms

[pedz]

I need either a

1) new language
2) new JS library
3) both 1 and 2
4) new way of thinking

Given:

Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <[email protected]>

I thought I'd be brave and ask here rather than there.

More and more in browsers the programming model is becoming event
driven. Take a typical Ajax call. My personal thought process is
something like:

1) Send the Ajax request
2) wait for it to get back
3) dig out the piece I need
4) send the next Ajax request
5) wait for it to complete
6) etc.

The problem is that steps 2 and 5 are done by setting up call back
handlers and so the result is that I do not get to "see" the list of
steps.

In today's particular adventure, I'm not doing Ajax requests but
working with Web Workers which have the same event driven
characteristic. I could maybe change my thinking to not mind this at
all but then I tried hooking up JSpec as a testing framework and it
all fell apart. JSpec at its root is very sequenctial. And I'm going
to bump into this same problem almost everywhere I go.

This got me thinking about a JS library which would create a thing. I
don't want to call it a "thread" nor a "context" because both of those
terms have so much meaning. So, for now, I'm going to call it a VSF
for Virtual Stack Frame.

To start, the VSF has a "pc" and a list of "instructions". The pc
starts at 0 and works forward. The instructions are calls to
Javascript ... here is my first weakness ... "functions" ? (I hope
thats right.)

What little I've used JS (most of it via Prototype (blush)), I really
like the bind and bindAsEventHandler so that I can get the "this" set
like I want. So, I was going to allow the user to specify the value
of "this" as well as a list of arguments to pass to the function.
Each of these functions needs a way to get back to the VSF so it would
either be passed as an argument or somehow accessable via the context.
JSpec uses the "with" statement for this but I know that Crockford, in
particular, dislikes the with statement.

The details of how the interface to the functions works has a lot of
options but in general, the idea is that a function can tell the VSF
to not proceed to the next instruction. Instead the VSF would just
exit
(return). For example, each instruction could return true if the next
instruction should be executed and false if not. I suppose it could
be
part of the instruction's specification.

Lets say that an instruction starts an Ajax call. It would set its
completion handler to call vsf.resume where vsf is an instance of a
VSF which initiated the Ajax call. The instruction itself would
return false or do whatever is needed to cause the VSF to not go to
the next instruction.

The call to vsf.resume picks up at the next instruction and continues.

Added entry points to VFS would be to get and set "instance" variables
(as Ruby calls them) and also to chain VSF's so that a stack of VSF's
can be created.

At this point, there is enough power to be dangerous. The user
creates his VSF instances and specifies the list of instructions.
Calls vsf.resume and off it goes.

More power could be added by adding features like being able to muck
with the PC, being able to "return" from the VSF. The other idea was
to implant a list of objects with the connotation that the list of
instructions would be executed once with each object. The
possibilities expand rather quickly which is what brought up point #1
way up at the start of this.

Perhaps, as a second evolution to this, a DSL could be wrapped around
it.

Also, I've been thinking in "single threaded" terms but a VSF could
have a parent concept perhaps called a VPS (Virtual Program Sequence)
which is just a list of instructions. Then a VSF would be started
from a VPS. The idea is that multiple instances of the same VPS could
be running around making a mess of things all at the same time. This
would introduce the need of locking, etc.

But, you ask, what about JSpec? Well, it would need to be redone to
use VSFs but I think the majority of it would work as is. And that is
a
major objective: to be able to retrofit existing programs to use VSFs
with
a minimum of effort.

By now, I hope you get the gist of all this.

I suppose my questions are:

1) Has this already been done somewhere? It seems like a rather
obvious place to come to. I've found a few "multithreaded javascript"
attempts but the seem to be going about it the wrong way implementing
particular solutions rather than a general solution.

2) Any particular thing above cause your face to melt in fear?

Thank you for your time,
pedz

 

[David Mark]

I need either a

 1) new language

And why do you need a new language?

 2) new JS library

A new JS library to do what?

 3) both 1 and 2
 4) new way of thinking

#4 would be my guess.

Given:

Yes, that's quite evident.

I thought I'd be brave and ask here rather than there.

Brave? Regardless, people who don't know JS are not the best people
to ask about JS.

More and more in browsers the programming model is becoming event
driven.

Do you mean reliant on asynchronous operations (e.g. XHR, SQL, etc.)?

Take a typical Ajax call.  My personal thought process is
something like:

 1) Send the Ajax request
 2) wait for it to get back

You don't have to wait for it to get back. The request object calls
you when it is ready (or has given up).

 3) dig out the piece I need
 4) send the next Ajax request
 5) wait for it to complete
 6) etc.

The problem is that steps 2 and 5 are done by setting up call back
handlers and so the result is that I do not get to "see" the list of
steps.

So you would prefer to use synchronous XHR calls? Unfortunately, they
are unusable as they block the browser UI. Of course, that didn't
stop Dojo.

In today's particular adventure, I'm not doing Ajax requests but
working with Web Workers which have the same event driven
characteristic.

In other words, they call back asynchronously.

I could maybe change my thinking to not mind this at
all but then I tried hooking up JSpec as a testing framework and it
all fell apart.

You are either using it incorrectly or it is unsuited to test browser
scripts.

JSpec at its root is very sequenctial.  And I'm going
to bump into this same problem almost everywhere I go.

It sounds as if the problem is JSpec.

Patient: Doc, it hurts when I do this.
Doctor: Don't do *that*.

So find another testing framework.

This got me thinking about a JS library which would create a thing.  I
don't want to call it a "thread" nor a "context" because both of those
terms have so much meaning.

You'd be hard-pressed to call it a thread as JS implementations are
single-threaded.

The term "context" has no meaning by itself. But add "execution" and
it is well-defined in JS. Well, unless you are the Dojo authors.

dojo.partial = function(/*Function|String*/method /*, ...*/){
// summary:
// similar to hitch() except that the scope object is left to be
// whatever the execution context eventually becomes.

Did they mean "scope" or "execution context"? Of course, the answer
is neither. But they aren't alone in such foolishness. The - this -
object is referred to as "scope" in virtually every blob of JS posted
to the Web in the last decade. I thought it was humorous that the
Dojo "experts" managed to refer to it as both "scope" and "execution
context" in the same sentence. That's certainly raising the bar for
confusion.

So, for now, I'm going to call it a VSF
for Virtual Stack Frame.
Okay.


To start, the VSF has a "pc" and a list of "instructions".  The pc
starts at 0 and works forward.  The instructions are calls to
Javascript ... here is my first weakness ... "functions" ?  (I hope
thats right.)

Hard to say at this point.

What little I've used JS (most of it via Prototype (blush)),

We all make mistakes. Admitting them is the first step to recovery.

I really
like the bind and bindAsEventHandler so that I can get the "this" set
like I want.

Yes! You aren't as clueless as you think (at least not in comparison
to the authors of most "major" JS libraries).

So, I was going to allow the user to specify the value
of "this" as well as a list of arguments to pass to the function.

Yes, I believe that is what Prototype calls "bind" (similar to
Function.prototype.bind found in the latest incarnation of ES). Such
a construct can be very useful.

Each of these functions needs a way to get back to the VSF so it would
either be passed as an argument or somehow accessable via the context.

I imagine you mean scope.

JSpec uses the "with" statement for this but I know that Crockford, in
particular, dislikes the with statement.

Nobody likes it (and for very good reasons), though I did notice it
about a hundred lines in in my review of Dojo 1.4. They are rebels
for sure.

The details of how the interface to the functions works has a lot of
options but in general, the idea is that a function can tell the VSF
to not proceed to the next instruction.  Instead the VSF would just
exit
(return).

It sounds like you want a unit testing framework that can handle test
functions that do asynchronous operations. Such things are already
out there. I wrote one over the winter for My Library. In short,
every unit test function receives a callback function from the
framework. When each test completes (synchronously or
asynchronously), it calls that function. The callback function logs
the result and calls the next test function in the queue.

For example, each instruction could return true if the next
instruction should be executed and false if not.  I suppose it could
be
part of the instruction's specification.

Interesting take. If you return true/false to indicate synchronous/
asynchronous, what will indicate success/failure? ISTM it would be
much simpler to have every function use the callback.

Lets say that an instruction starts an Ajax call.  It would set its
completion handler to call vsf.resume where vsf is an instance of a
VSF which initiated the Ajax call.

Why not keep it simple, at least for starters? Why do you need any
special "VSF" objects at all? And points off for using the term
"instance" as it doesn't really apply to JS objects (despite the
unfortunately named instanceof operator).

The instruction itself would
return false or do whatever is needed to cause the VSF to not go to
the next instruction.

The call to vsf.resume picks up at the next instruction and continues.

See what I mean? The root of your problem is that you are trying to
envision and design a complicated system where a simple one would
suffice. That's a recurring theme for JS projects of all shapes and
sizes (particularly libraries).

Added entry points to VFS would be to get and set "instance" variables
(as Ruby calls them)

Never mind what Ruby calls them. Who is she anyway?

and also to chain VSF's so that a stack of VSF's
can be created.

I don't see why you need one "VSF", let alone a stack of them.

At this point, there is enough power to be dangerous.

My thoughts exactly.

The user
creates his VSF instances and specifies the list of instructions.
Calls vsf.resume and off it goes.

Calls resume to start? It's already confused and it isn't even off
the drawing board.

More power could be added by adding features like being able to muck
with the PC,

Muck with the PC?

being able to "return" from the VSF.

You return when the queue is empty, which happens after each of the
queued tests has either completed or timed out. And to alleviate any
confusion, the "queue" I refer to is just an array of test functions.

The other idea was
to implant a list of objects with the connotation that the list of
instructions would be executed once with each object.

You should settle on one (preferably simple) idea to start with.

The
possibilities expand rather quickly which is what brought up point #1
way up at the start of this.

You are simply over-thinking the problem.

Perhaps, as a second evolution to this, a DSL could be wrapped around
it.

You have to create something before it can evolve.

Also, I've been thinking in "single threaded" terms but a VSF could
have a parent concept perhaps called a VPS (Virtual Program Sequence)
which is just a list of instructions.  Then a VSF would be started
from a VPS.  The idea is that multiple instances of the same VPS could
be running around making a mess of things all at the same time.)

I think you are going to make a fine mess.

This
would introduce the need of locking, etc.

So why introduce it?

But, you ask, what about JSpec?

What about it?

Well, it would need to be redone to
use VSFs but I think the majority of it would work as is.
Whatever.

And that is
a
major objective: to be able to retrofit existing programs to use VSFs
with
a minimum of effort.
Why?


By now, I hope you get the gist of all this.
Somewhat.


I suppose my questions are:

1) Has this already been done somewhere?

All of it?! No idea.

It seems like a rather
obvious place to come to.  I've found a few "multithreaded javascript"
attempts but the seem to be going about it the wrong way implementing
particular solutions rather than a general solution.

I think you are barking up the wrong tree with that concept.

2) Any particular thing above cause your face to melt in fear?

No, but I do feel a headache coming on. Perhaps somebody else can
recommend an existing unit testing framework for JS. ISTM that's
would be the best thing for you at this point. If you like it,
perhaps you can copy and evolve it to fit your grand plans for stacked
VSF's and multi-threaded JS.

Best of luck to you!

 

[Thomas 'PointedEars' Lahn]

Given:

You misquoted one of my signatures, and failed to provide attribution.

I thought I'd be brave and ask here rather than there.

Good idea.

More and more in browsers the programming model is becoming event
driven.

It has been event-driven ever since (DOM Level 0).

Take a typical Ajax call.

There are no "Ajax call"s.

My personal thought process is something like:

1) Send the Ajax request

There are no "Ajax request"s either. There are HTTP requests.

2) wait for it to get back

.... the HTTP response?

3) dig out the piece I need
4) send the next Ajax request
5) wait for it to complete
6) etc.

OK, except of the terminology.

The problem is that steps 2 and 5 are done by setting up call back
handlers and so the result is that I do not get to "see" the list of
steps.

What does this mean? What exactly do you want to achieve?

[snip problems with "JSpec"]
JSpec at its root is very sequenctial. And I'm going to bump into this
same problem almost everywhere I go.

You have failed to describe the problem you have.

This got me thinking about a JS library which would create a thing. I
don't want to call it a "thread" nor a "context" because both of those
terms have so much meaning. So, for now, I'm going to call it a VSF
for Virtual Stack Frame.

Those who think they need to invent catchy or sopisticated sounding but
undescriptive/misleading terms seldom know what they are doing. You appear
to be among them.

To start, the VSF has a "pc" and a list of "instructions". The pc
starts at 0 and works forward. The instructions are calls to
Javascript ... here is my first weakness ... "functions" ? (I hope
thats right.)

There is no "Javascript", but everything that can be invoked with a
CallExpression in these langueges can reasonably be called a function at
least. If that is a property of an object, it is a method, too.

What little I've used JS (most of it via Prototype (blush)),

IOW, you have not used it at all. Sorry.

I really like the bind and bindAsEventHandler so that I can get the "this"
set like I want.

You don't need (or want) bind() aso. for that.

So, I was going to allow the user to specify the value
of "this" as well as a list of arguments to pass to the function.

Not a bad idea in itself. Function.prototype.apply() can take care of it.

[snip description for a solution]

By now, I hope you get the gist of all this.

You appear to be describing at great length a potentially wrong solution for
a non-problem.

I suppose my questions are:

1) Has this already been done somewhere? It seems like a rather
obvious place to come to. I've found a few "multithreaded javascript"
attempts but the seem to be going about it the wrong way implementing
particular solutions rather than a general solution.

A solution for what? Working around the shortcomings of a borken testing
framework that cannot be suited to the task?

2) Any particular thing above cause your face to melt in fear?

No, but that does not mean it is any good.


PointedEars

 

[Garrett Smith]

And why do you need a new language?


A new JS library to do what?

I wonder the same.

[...]

All of it?! No idea.

YUI Test provides async testing. It's good, but has some disadvantages
that have really bugged me. I added a lot of patches to my own copy but
got tired of doing that. YUI team doesn't fix stuff as fast as I need it
(usually takes about a year or so) and they don't take patches unless
you go through their legal paperwork. NO thanks. I'll just patch it and
go and I'll advise anyone to do the same; filing bugs on YUI is helpful
for the authors it takes a long time to get a fix (if ever).

I started on a testing framework that provides async testing
functionality. It's essentially an event-driven tree. Tests don't
complete in order, necessarily and you can have deferred segments, as in:

testFudgeHasPecansWhenDone : function() {

var hasPecans;
fudge.setUpReq();
this.waitForCondition(fudgeDone, deferred);

function deferred() {
Assert.that(hasPecans, Constraint.strictEquals(true));
}
function fudgeDone() {
var hasPecans = !!fudge.getPecans();
}
}
....

I'd like to represent it visually in an expandable tree as nested lists
and where a test case fails, the cause of the failure; the test
function, its error, and the error's stack trace are shown.

There should also be a feature to rerun that one test, without having to
rerun the entire test case.

I planned to NUnit-style use constraints, as above, to make it easily
extensible with your own constraints.

Assert.that(myFunction, functionCallsAlert);


Where Assert.that would take both arguments and call the second argument
with the first argument, expecting exactly a true result.

I've not gotten that far with it, but if you (or anyone) is interested
in building on it, send a mail or post here.

Regardless, I suggest answering the first two questions first. If you
need a new language, the whole thing may be a total waste of time. I
know why I unit test. I've been doing it for years and I am good at it;
I just haven't finished my own test runner. I'd like to get paid to do
that, actually.

Garrett

 

[Garrett Smith]

pedz wrote:

[...]

[snip problems with "JSpec"]
JSpec at its root is very sequenctial. And I'm going to bump into this
same problem almost everywhere I go.

You have failed to describe the problem you have.

I understood it as the problem is wanting to test async calls, but
finding synchronous testing frameworks to fail at that. Did I get that
right?

[...]

You don't need (or want) bind() aso. for that.

Nope. Moreover, using bind ubiquitiously to handle variable this is
inelegant and inefficient.

Garrett

 

[pedz]

From my original post:

The problem is that steps 2 and 5 are done by setting up call back
handlers and so the result is that I do not get to "see" the list of
steps.

Part of my original "I need" list was #4 -- perhaps I need to just
think differently.

But my problem is that I'd like to be able to follow the flow of a
program using async events like I do other programs. I look down a
list of statements and see the sequence of steps being taken.

Granted, that is not necessary. I've just come to be use to it.

Wouldn't be more intuitive if I could write:

result = doSomeCall();
if (result == good)
beHappy();
else
beSad();

where doSomeCall() starts an asynchronous sequence of steps and the
end result is returned?

 

[Thomas 'PointedEars' Lahn]

But my problem is that I'd like to be able to follow the flow of a
program using async events like I do other programs. I look down a
list of statements and see the sequence of steps being taken.

Granted, that is not necessary. I've just come to be use to it.

In that case I suggest you use the script consoles built into many browsers,
tools like Firebug, other debuggers (set a breakpoint in the callback), or
use a logging feature in the callback (which, again, is often provided as a
built-in with console.log()).

Wouldn't be more intuitive if I could write:

result = doSomeCall();
if (result == good)
beHappy();
else
beSad();

where doSomeCall() starts an asynchronous sequence of steps and the
end result is returned?

No, because "asynchronous" implies that the result may not yet be available
when doSomeCall() returns.


HTH

PointedEars

 

[Scott Sauyet]

[ ... ]
This got me thinking about a JS library which would create a thing.  I
don't want to call it a "thread" nor a "context" because both of those
terms have so much meaning.  So, for now, I'm going to call it a VSF
for Virtual Stack Frame. [ ... ]

If I have it right, both David and Thomas were somewhat misdirected by
your talk of the testing framework. You are not looking particularly
to rewrite the testing framework but to create a tool that helps you
make a list of possibly asynchronous calls look as much like a list of
synchronous ones as possible, right?

A don't know of a tool out there, but I can imagine the start to an
interface to building one, but I get stuck very quickly at forks. How
do you handle, say, an AJAX call (sorry Thomas!) that fails? Do you
add conditionals? Do you then need loops? Are you already on your
way then to a DSL?

Putting that aside for the moment, would an interface like the implied
Sequencer in the following meet your requirements?

var sequence = new Sequence(
function() {/* set up AJAX call */},
function() {/* perform AJAX call 1 */}, // #1
function() {/* update DOM *},
function() {/* perform AJAX call 2 */}
function() {/* perform further DOM updates */}
);
sequence.start();

where the function labeled #1 above might look like this:

function(data) {
var theSeq = this;
MyAjaxFunction({
url: 'myScript.php',
method: 'POST',
postData: {a : data.a, b:data.b},
success: function(results) {theSeq.next(results)},
failure: function(error) {theSeq.abort()}
})
}

Such a constructor would generate objects that have methods such as
start, next, and abort. Each function in the sequence is called with
"this" bound to the sequence itself. If the function returns true,
then the next function is called immediately. Otherwise the sequence
is paused until its "next" method is called. You could use a property
of the sequence object to hold data that needs to be shared among the
steps,

Is that close to what you're looking for? If so, it doesn't sound
particularly difficult to write. But if you start talking about
branching or looping, it starts to sound more like language design,
like a much larger undertaking.

 

[Thomas 'PointedEars' Lahn]

No, because "asynchronous" implies that the result may not yet be
available when doSomeCall() returns.

I think you might be looking for something like

doSomeCall(beHappy, beSad);

But that alone will not help with your "problem".


PointedEars

 

[pedz]

[ ... ]
This got me thinking about a JS library which would create a thing.  I
don't want to call it a "thread" nor a "context" because both of those
terms have so much meaning.  So, for now, I'm going to call it a VSF
for Virtual Stack Frame. [ ... ]

If I have it right, both David and Thomas were somewhat misdirected by
your talk of the testing framework.  You are not looking particularly
to rewrite the testing framework but to create a tool that helps you
make a list of possibly asynchronous calls look as much like a list of
synchronous ones as possible, right?

A don't know of a tool out there, but I can imagine the start to an
interface to building one, but I get stuck very quickly at forks.  How
do you handle, say, an AJAX call (sorry Thomas!) that fails?  Do you
add conditionals?  Do you then need loops?  Are you already on your
way then to a DSL?

Putting that aside for the moment, would an interface like the implied
Sequencer in the following meet your requirements?

  var sequence = new Sequence(
    function() {/* set up AJAX call */},
    function() {/* perform AJAX call 1 */}, // #1
    function() {/* update DOM *},
    function() {/* perform AJAX call 2 */}
    function() {/* perform further DOM updates */}
  );
  sequence.start();

where the function labeled #1 above might look like this:

  function(data) {
    var theSeq = this;
    MyAjaxFunction({
      url: 'myScript.php',
      method: 'POST',
      postData: {a : data.a, b:data.b},
      success: function(results) {theSeq.next(results)},
      failure: function(error) {theSeq.abort()}
    })
  }

Such a constructor would generate objects that have methods such as
start, next, and abort.  Each function in the sequence is called with
"this" bound to the sequence itself.  If the function returns true,
then the next function is called immediately.  Otherwise the sequence
is paused until its "next" method is called.  You could use a property
of the sequence object to hold data that needs to be shared among the
steps,

Is that close to what you're looking for?  If so, it doesn't sound
particularly difficult to write.  But if you start talking about
branching or looping, it starts to sound more like language design,
like a much larger undertaking.

Thank you Scott... you helped a lot.

Yes. That is what I am talking about.

As far as errors, the first step is to have all the handlers funnel
back to a common point and that point returns a single "result". Care
would be needed for the case that two handlers fire but lets not go
there yet. Your approach of having a next and an abort I like too.

The most primitive control structure would be a "skip if" statement.
This provides a crude but still fairly readable if/then/else
structure. The "skip if" would skip one statement if the condition is
true. The next statement is usually a "branch to error code" or
"return error code up to the next higher level". A DSL for more
sophisticated loops could build on top of this simple structure.

One thing I thought about between posts is the Sequence needs a way to
start with at least one input argument. But, that could be done via
the get and set interfaces to the "Sequence local" variables.

 

[Scott Sauyet]

pedz wrote:

[ ... ]
This got me thinking about a JS library which would create a thing.  I
don't want to call it a "thread" nor a "context" because both of those
terms have so much meaning.  So, for now, I'm going to call it a VSF
for Virtual Stack Frame. [ ... ]

[ ... ] would an interface like the implied Sequencer in the
following meet your requirements?

  var sequence = new Sequence(
    function() {/* set up AJAX call */},
    function() {/* perform AJAX call 1 */}, // #1
    function() {/* update DOM *},
    function() {/* perform AJAX call 2 */}
    function() {/* perform further DOM updates */}
  );
  sequence.start();
[ ... ]
Is that close to what you're looking for?  If so, it doesn't sound
particularly difficult to write.  But if you start talking about
branching or looping, it starts to sound more like language design,
like a much larger undertaking.

Yes.  That is what I am talking about.

As far as errors, the first step is to have all the handlers funnel
back to a common point and that point returns a single "result".  Care
would be needed for the case that two handlers fire but lets not go
there yet.  Your approach of having a next and an abort I like too.

I'm not sure how the notion of handlers really fits with this model.
But as for simultaneous actions, all implementations of ECMAScript
I've used appear single-threaded. (I've heard that some versions of
Opera may differ, but I've never noticed it.) Things simply don't
happen at the same time in this model.

The most primitive control structure would be a "skip if" statement.
This provides a crude but still fairly readable if/then/else
structure.  The "skip if" would skip one statement if the condition is
true.  The next statement is usually a "branch to error code" or
"return error code up to the next higher level".  A DSL for more
sophisticated loops could build on top of this simple structure.

I think even simpler for a first pass would be to have each step in
the sequence do it's own gate-keeping:

if (!this.data.condition1) return;
// ...

One thing I thought about between posts is the Sequence needs a way to
start with at least one input argument.  But, that could be done via
the get and set interfaces to the "Sequence local" variables.

Sequence.start could not return any meaningful result from the entire
sequence: at best you would be able to define a callback to handle
it's result; sorry, but that's just the nature of asynchronous
processing. But start could be supplied an input parameter, and abort
could accept and supply error messages.

That would imply event handlers associated with the Sequence,
something like onCompete and onAbort. Is that what you meant above?

 

[pedz]

pedz wrote:
[ ... ]
This got me thinking about a JS library which would create a thing.  I
don't want to call it a "thread" nor a "context" because both of those
terms have so much meaning.  So, for now, I'm going to call it a VSF
for Virtual Stack Frame. [ ... ]
[ ... ] would an interface like the implied Sequencer in the
following meet your requirements?
  var sequence = new Sequence(
    function() {/* set up AJAX call */},
    function() {/* perform AJAX call 1 */}, // #1
    function() {/* update DOM *},
    function() {/* perform AJAX call 2 */}
    function() {/* perform further DOM updates */}
  );
  sequence.start();
[ ... ]
Is that close to what you're looking for?  If so, it doesn't sound
particularly difficult to write.  But if you start talking about
branching or looping, it starts to sound more like language design,
like a much larger undertaking.

Yes.  That is what I am talking about.

As far as errors, the first step is to have all the handlers funnel
back to a common point and that point returns a single "result".  Care
would be needed for the case that two handlers fire but lets not go
there yet.  Your approach of having a next and an abort I like too.

I'm not sure how the notion of handlers really fits with this model.
But as for simultaneous actions, all implementations of ECMAScript
I've used appear single-threaded.  (I've heard that some versions of
Opera may differ, but I've never noticed it.)  Things simply don't
happen at the same time in this model.

The end result of what I'm trying to do would be similar to pthreads;
it would implement the concept of threading on top of a single
threaded machine just like pthreads, before multi-CPU or multi-
threaded OSs, could cause a single process to look like multiple
threads. In truth, only one thread was running at a time.

The HTML5 spec defines that only one thread per <something> ...
"similar browsing contexts" I think is the term. But it also defines
that a web worker will be at least a separate thread but can be a
separate process.

I think even simpler for a first pass would be to have each step in
the sequence do it's own gate-keeping:

    if (!this.data.condition1) return;
    // ...


Sequence.start could not return any meaningful result from the entire
sequence: at best you would be able to define a callback to handle
it's result; sorry, but that's just the nature of asynchronous
processing.  But start could be supplied an input parameter, and abort
could accept and supply error messages.

That would imply event handlers associated with the Sequence,
something like onCompete and onAbort.  Is that what you meant above?

I found "QUnit" which is JQuery's unit test framework. It has the
concept of "stopping" the test sequencing with an external call to
"start" to resume. It creates a queue of tasks and then runs through
them until "block" becomes true and then it exits. "start" turns off
block and then calls process to resume the execution. That has the
basic gist of what I was thinking about except it is limited to just
testing. I was hoping for a more general library.

Whether I keep going down this path, I'm not sure. Mostly it just
sounds fun. But the places where the javascript guys can help me is
with the lower level details.

For example, is "bind" a good idea or bad? What should be used
instead?

Thanks,
Perry

 

[Scott Sauyet]

The end result of what I'm trying to do would be similar to pthreads;
it would implement the concept of threading on top of a single
threaded machine just like pthreads, before multi-CPU or multi-
threaded OSs, could cause a single process to look like multiple
threads.  In truth, only one thread was running at a time.

I think a thread-scheduling algorithm for Javascript would be
extremely tricky. There is no real notion of suspending execution of
a function, only of scheduling the execution after a delay. Your code
would essentially have to manage the stopping and starting of
functions internally. It's not even clear to me what that would
mean...

The HTML5 spec defines that only one thread per <something> ...
"similar browsing contexts" I think is the term.  But it also defines
that a web worker will be at least a separate thread but can be a
separate process. [ ... ]

Have you used any implementations of this?

I found "QUnit" which is JQuery's unit test framework.  It has the
concept of "stopping" the test sequencing with an external call to
"start" to resume.  It creates a queue of tasks and then runs through
them until "block" becomes true and then it exits.  "start" turns off
block and then calls process to resume the execution.  That has the
basic gist of what I was thinking about except it is limited to just
testing.  I was hoping for a more general library.

Yes, QUnit is similar, and any asynchronous testing toolkit probably
offers analogous capabilities.

Whether I keep going down this path, I'm not sure.  Mostly it just
sounds fun.  But the places where the javascript guys can help me is
with the lower level details.

For example, is "bind" a good idea or bad?  What should be used
instead?

I think bind (called "hitch" in some systems) is pretty well essential
for complicated event-driven systems unless they are thoroughly object-
oriented, which I would not recommend for the Web.

 

[David Mark]

The end result of what I'm trying to do would be similar to pthreads;
it would implement the concept of threading on top of a single
threaded machine just like pthreads, before multi-CPU or multi-
threaded OSs, could cause a single process to look like multiple
threads.  In truth, only one thread was running at a time.

I think a thread-scheduling algorithm for Javascript would be
extremely tricky.  There is no real notion of suspending execution of
a function, only of scheduling the execution after a delay.  Your code
would essentially have to manage the stopping and starting of
functions internally.  It's not even clear to me what that would
mean...

The HTML5 spec defines that only one thread per <something> ...
"similar browsing contexts" I think is the term.  But it also defines
that a web worker will be at least a separate thread but can be a
separate process. [ ... ]

Have you used any implementations of this?

I found "QUnit" which is JQuery's unit test framework.  It has the
concept of "stopping" the test sequencing with an external call to
"start" to resume.  It creates a queue of tasks and then runs through
them until "block" becomes true and then it exits.  "start" turns off
block and then calls process to resume the execution.  That has the
basic gist of what I was thinking about except it is limited to just
testing.  I was hoping for a more general library.

Yes, QUnit is similar, and any asynchronous testing toolkit probably
offers analogous capabilities.

Whether I keep going down this path, I'm not sure.  Mostly it just
sounds fun.  But the places where the javascript guys can help me is
with the lower level details.

For example, is "bind" a good idea or bad?  What should be used
instead?

I think bind (called "hitch" in some systems) is pretty well essential
for complicated event-driven systems unless they are thoroughly object-
oriented, which I would not recommend for the Web.

It's called "hitch" in Dojo, "delegate" in ExtJS and God knows what in
other libraries. Personally, I've never felt the need to encapsulate
call/apply in a function. However, per several requests, I recently
added a bind function that mimics the new Function.prototype.bind to
My Library (will be in the next build).

 

[pedz]

I think a thread-scheduling algorithm for Javascript would be
extremely tricky.  There is no real notion of suspending execution of
a function, only of scheduling the execution after a delay.  Your code
would essentially have to manage the stopping and starting of
functions internally.  It's not even clear to me what that would
mean.

Right. I can't actually do a context switch nor do I even want to.
The higher level code would likely break.

Remember what a program is -- all programs. Its a sequence of
instructions. Some instructions modify the PC. Some modify the
state. Thats it. On top of that is pile tons of sugar to make it so
that humans can program.

In this new paradigm, the "instruction" is a single javascript
function. The program fragments are lists of these instructions. The
PC is an index into this list. Any type of looping will be syntactic
sugar to modify this PC. The calls to create, as we called them,
"Sequence local" variables is what saves and retrieves the state.

All of that I'm comfortable with. I've been doing compilers and such
for many years. But to write a compiler, I need to talk to the chip
designers (or read their books). In this project I need to talk to
the Javascript guys.

The HTML5 spec defines that only one thread per <something> ...
"similar browsing contexts" I think is the term.  But it also defines
that a web worker will be at least a separate thread but can be a
separate process. [ ... ]

Have you used any implementations of this?

Yes. That is what triggered this. I'm writing (as a self-tutorial)
what I guess is called a server-less web application. Its just a pile
of HTML and javascript. I have a "loader" and a "loader_worker" with
the loader_worker being in a web worker. The loader and loader_worker
talk back and forth via the message facility. It is asynchronous as
you might expect.

The original test rig using JSpec called the loader and then checked
to see if the load failed (it was a bad request to test the error
path) and the check was / is being done before the loader_worker would
communicate back to the loader that the request failed.

That doesn't really prove it is two separate threads I suppose but it
definitely appears as if it is.

Yes, QUnit is similar, and any asynchronous testing toolkit probably
offers analogous capabilities.

Any pointers to specific libraries in this area would help.

I think bind (called "hitch" in some systems) is pretty well essential
for complicated event-driven systems unless they are thoroughly object-
oriented, which I would not recommend for the Web.

Ok.

Thanks to all for helping out.

 

[Scott Sauyet]

Right.  I can't actually do a context switch nor do I even want to.
The higher level code would likely break.

Remember what a program is -- all programs.  Its a sequence of
instructions.  Some instructions modify the PC.  Some modify the
state.  Thats it.  On top of that is pile tons of sugar to make it so
that humans can program.

In this new paradigm, the "instruction" is a single javascript
function.  The program fragments are lists of these instructions.  The
PC is an index into this list.  Any type of looping will be syntactic
sugar to modify this PC.  The calls to create, as we called them,
"Sequence local" variables is what saves and retrieves the state.

Okay, I seriously underestimated your ambition. You're talking about
more than a DSL even, essentially a new language to be implemented
atop Javascript.

All of that I'm comfortable with.  I've been doing compilers and such
for many years.  But to write a compiler, I need to talk to the chip
designers (or read their books).  In this project I need to talk to
the Javascript guys.

The HTML5 spec defines that only one thread per <something> ...
"similar browsing contexts" I think is the term.  But it also defines
that a web worker will be at least a separate thread but can be a
separate process. [ ... ]

Have you used any implementations of this?

Yes.  That is what triggered this.  I'm writing (as a self-tutorial)
what I guess is called a server-less web application.  Its just a pile
of HTML and javascript.  I have a "loader" and a "loader_worker" with
the loader_worker being in a web worker.  The loader and loader_worker
talk back and forth via the message facility.  It is asynchronous as
you might expect.

The original test rig using JSpec called the loader and then checked
to see if the load failed (it was a bad request to test the error
path) and the check was / is being done before the loader_worker would
communicate back to the loader that the request failed.

That doesn't really prove it is two separate threads I suppose but it
definitely appears as if it is.

It most likely is. It's just that the HTML5 spec is still-evolving,
and I don't know how well the Web Worker stuff has settled down, nor
how good the implementations are. I haven't had any need for them
yet.

Any pointers to specific libraries in this area would help.

I don't have any links off-hand. But any test framework that allows
asynchronous calls presumably needs some similar facility.

Good luck,

-- Scott