«

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, <f806at$ail$1$8300d...@news.demon.co.uk>

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

On Jun 13, 6:38*pm, pedz <pedz...@gmail.com> wrote:
> 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:
>
> > 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, <f806at$ail$1$8300d...@news.demon.co.uk>

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!

pedz wrote:

> 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, <f806at$ail$1$8300d...@news.demon.co.uk>

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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

On 6/13/2010 4:56 PM, David Mark wrote:
> On Jun 13, 6:38 pm, pedz<pedz...@gmail.com> wrote:
>> 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?
>

I wonder the same.

[...]

>>
>> I suppose my questions are:
>>
>> 1) Has this already been done somewhere?
>
> 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

On 6/13/2010 5:41 PM, Thomas 'PointedEars' Lahn wrote:
> 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?

[...]

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

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

Garrett

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?

pedz wrote:

> 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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

On Jun 13, 6:38*pm, pedz <pedz...@gmail.com> 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. [ ... ]

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.

--
Scott

Thomas 'PointedEars' Lahn wrote:

> pedz wrote:
>> 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.

I think you might be looking for something like

doSomeCall(beHappy, beSad);

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


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

On Jun 13, 8:38*pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> On Jun 13, 6:38*pm, pedz <pedz...@gmail.com> 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. [ ... ]
>
> 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.