Create a system of addressable instructions

At the moment, the only way to give somebody a ‘hole’ for a given location in a Script, is for it to unstage itself at that location, and for you to give somebody else your Execution, and then run the Execution up to that unstaging. This is obviously terrible: it's inflexible, and precludes several useful abstractions:

Somebody else can't have a handle to a future location, only a ‘current’ one, for a given Execution's definition of ‘current.’ This specifically causes the (still unsolved) first-stage problem, #6.
Somebody can't have handles to multiple locations (yes, they can have multiple Executions at different points; but those represent different branches in history; and for all intents and purposes, those are each still a handle to aforementioned single location in the Script … for that given branch of execution.) This is very un-Paws; one of the most important guiding principles of Paws' original design work was “anytime something can be multiple instead of single, find a way to make it multiple.” We should do that here.
Somebody can't get a handle, unless the Execution itself creates one and gives it to them. I'm not convinced doing so is good practice anyway (if you haven't noticed, I'm very attached to coproduction), but I don't feel like it's necessarily necessary to preclude the possibility of doing so.

In addition, there's lots of issues (#17) with the desired non-linear executions we're discussing now that might be solved, or at least de-emphasized, by being able to specifically address instructions in a Script.

So, I don't have a specific solution to these I like, but the problems above obvious imply a particular sort of solution: a way to create stagings (resumptions), that represent a resumption at a specific place in the Script. (Anybody remember ‘holes?’)

To do that, we need a way to identify the aforementioend ‘specific place’ in a Script. Which, unless we can come up with an even more crazy-intricate folded-over-itself multi-dismensional syntax than Tires, basically means introducing naming to the syntax, somehow.

I like the idea of using a single-consumption SSA type thing. Perhaps we can still have coproduction if we do something like this? (Excuse the horrible syntax.)

implementation console trace[] Hi;
one: foo[] a b c d;
two(one): implementation console trace[] Yo!;
three: infrastructure affix[] [$two] $one

Summary: statements can have a preamble, which can give them a "name" and/or specify which other named statements they order-depend upon.

[] refers to the hole in that statement - i.e. individual statements are linear. This allows coproduction to occur.

The "name" can be referenced with form $name which refers to the last data-value returned from the statement (i.e. at the end). The name is lexically scoped and its value may only be consumed once (dynamic scoping via locals must be used in other cases). This causes the statement to wait for that data value as soon as it needs to pass it out, but is not the same as adding an order dependency - it will use it as soon as it's available and doesn't cause the entire statement to wait.

If the statement's preamble includes the form (a b c...), then statements a, b, and c must complete before the statement begins to execute.

Essentially, I think, this ends up turning each individual statement into its own Execution, effectively, in a way that's encoded into the Script. The names would be purely for lexical purposes; a compiled Script would probably only have SSA-style numbers or something.

Of course, statements don't need to be named to have an order dependency; one can write:

one: foo[] a b c d;
(one): implementation console print "foo completed"

I'm sure there are ways to make this less syntactically complex, but I think it is still inherently abstractable which is the main thing: someone could modify the parser (dynamically, of course) to always generate order dependencies on the statement above and in doing so create an imperative/synchronous language.

@devyn (note, first, that #16 is unrelated to this (except, perhaps, in that they'll need different namespaces of some sort, I suppose.) That's to do with an SSA form for describing dependencies in an instruction graph (that has nothing to do with semantics; it's explicitly syntactic); this is about naming nodes in that graph, with semantic purposes.)

So, what you're describing is basically the combination of #16 (almost, although your names are specifically data-value related, whereas my imagined syntax for #16 should allow any node to be depended upon by-name), combined with the partial/unhappy-making solution of retaining linearity for coproductive purposes I described today under #17 …

So. Yeah. Sounds like you've come up with some specific examples of what I was already considering, which is good, 'cuz it means we're on the same page. That said, I've expressed my concerns with this solution elsewhere.

Other than that, I didn't understand this statement: “This causes the statement to wait for that data value as soon as it needs to pass it out, but is not the same as adding an order dependency - it will use it as soon as it's available and doesn't cause the entire statement to wait.”

However, that said, none of this is related to what I was intending to convey with this Issue. I was intending something completely different, with this: non-lexical (unlike the SSA node-naming for dependency purposes), and with semantic meaning inside the language. Think about it as … hm … Objective-C's named arguments, for the Paws equivalent of ‘arguments.’ So, named holes. Except, unlike the original plans for holes, this wouldn't be creating a specific ‘hole’ in the Script, something special that has to be filled … it would be naming an existing node in the Script, and then by referring to that name, pre-emptively setting the return-value of that node. I think. Kinda. (So, queueing results to be used? Or something?)

This doesn't really relate to coproduction; it doesn't solve the problems in #17, nor does it even really interact with the current design. If we designed what I was trying to describe here on top of the current design without #17-style nonlinears, it'd still fit in: it could be used like old-school pipelining was; back then, I wanted to “result” multiple values quickly, with the intention of them filling in a series of subsequent holes in the thing we're resulting to. That didn't work out, but with this, we could queue up multiple results (multiple “arguments”) to a given Execution, by specifying which named-nodes to fill.

Basically, given

foo: some operation[]

The following will cause data dependency once execution of this statement reaches $foo (but it will be allowed to execute until that point):

other operation[] $foo

And the following won't depend on the data from foo but will wait until that entire statement completes until this statement can start:

(foo): other operation[]

And then this statement does both; it waits for foo to complete and depends on the data from it.

(foo): other operation[] $foo

So, no, these aren't explicitly data related; they're really just "named statements" and the (...) patttern and $... pattern are order dependency and data dependency respectively.

PratchettLovesYou / Issues

Create a system of addressable instructions #18