elliottcable changed the topic of #Paws.Nucleus to: http://Paws.mu — coming soon™ ... or not.
drparse has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<ELLIOTTCABLE>
devyn: I have a beautiful fix. for a lot of problems.
<ELLIOTTCABLE>
devyn: at least, the immediate-first-stage and interspersed-resumption problems; possibly others.
<ELLIOTTCABLE>
devyn: let me know what you think:
<ELLIOTTCABLE>
simply,
<ELLIOTTCABLE>
futures.
<ELLIOTTCABLE>
dunno why I didn't think of this sooner.
<ELLIOTTCABLE>
ignoring syntax, or real-world usage, for a moment,
<ELLIOTTCABLE>
embed instances of a particular native type in the Script.
<ELLIOTTCABLE>
an instance of that type can be in a state of incompleteness, or completion.
<ELLIOTTCABLE>
empower that type with the semantic that when involved in a combination while incomplete, that combination is unstated until the instance becomes complete.
<ELLIOTTCABLE>
(basically, these are inside-out Holes.)
<ELLIOTTCABLE>
that's basically enough right there, but to make them useful, we can boost them with new syntax, in addition to that special semantic.
<ELLIOTTCABLE>
introduce a lexical scoping system to cPaws, and introduce the "Future literal": basically, a named variable hole. you type a name with a special syntax somewhere; say, <foo>; and it drops a future in that place. anything that combines against that will be frozen if that combination is reached before the future is fulfilled.
<ELLIOTTCABLE>
I haven't decided *how* to fulfil futures, since so far I haven't allowed for a way to, well, pass them around (since the above leaves you unable to combine against them at all :P )
<ELLIOTTCABLE>
but there would have to be some syntax for that, too.
<ELLIOTTCABLE>
----------------
<ELLIOTTCABLE>
alongside this, and possibly complementary, I had another thought:
<ELLIOTTCABLE>
it might be beneficial to make *generic* executions (i.e. non-future-fulfillment ones; ones that can fill any hole) become … exclusive.
<ELLIOTTCABLE>
something like, "once I create a new execution for myself to hand to somebody, the previously-created one is invalidated."
<ELLIOTTCABLE>
only *branches* of the code made before invalidation
<ELLIOTTCABLE>
, would be valid.
<ELLIOTTCABLE>
this effectively means that only one external-to-onesself process has a handle on you at a given time. no possibility of interjection.
<ELLIOTTCABLE>
that would encourage the use of named holes, "futures", for complex interaction patterns; and preclude race conditions.
<ELLIOTTCABLE>
devyn: wrote down my thoughts. always helps me suss out the illogical bits and inconsistencies.