[PEAK] "Coherence" - a Trellis-like language w/error handling

[Sergey Schetinin]

I couldn't help but notice how the "reaction" part of bidirectional
propagation mirrors my ".filter_assign" proposal.

class Task1(Component):
    attrs(name='task1', start=1, length=2)
    @track # or compute
    def end(self):
        return self.start + self.length

    @end.filter_assign
    def end_assign(self, end):
        self.start += end - self.end
        return end

There's a circularity as self.end used in end_assign depends on
self.start that is changed  by end_assign, however if @track is used
it would just be using its previous value and in case of @compute it
can be special-cased for filter_assign in such a way that the
circularity is ignored and self.end is recalculated with new
self.start and the result is checked to be the same as the one
returned by end_assign, or end_assign for @compute rules wouldn't
return anything and the rerun of the compute rule itself would be used
as a result.


On Fri, Apr 24, 2009 at 21:04, P.J. Eby <pje at telecommunity.com> wrote:
> I ran across this yesterday, via reddit:
>
>  http://coherence-lang.org/
>
> The paper is very much worth reading, although I am still digesting all the
> ramifications of it.  Basically, the author has created a Trellis-like
> programming language, but with various additional twists.  In particular, it
> supports "micro-transactions" at a finer grain than the Trellis, as well as
> what might be called "structural transactions" for error handling.
>
> There is a notion in this language of "fences" and "latches" which can wrap
> an object such that if an error occurs as a result of changes passing
> through the "fence", then all changes inside the fence are rolled back to
> the corresponding latches where those changes were made.  However, the
> boundary isn't a call stack like try/except, it's the attributes or cells
> where the changes are made.
>
> In effect, it's like the old idea of having an "editor" or "buffer" object
> that holds changes to be applied all-at-once to another object, except that
> instead of using validation functions on the editor/buffer, this actually
> works by changing the target object, but rolling back all the changes if an
> error occurred as a result of any of the changes.
>
> In addition, it has the notion of "hypothetical execution", meaning that you
> can do something like, "suppose I set this and this and this...  what would
> happen?"  In other words, a mini-transaction that gets rolled back after you
> get your information.
>
> There's also "causal error handling", which basically means that you can get
> the equivalent of tracebacks between rules, when something makes something
> else blow up.
>
> Anyway, these features aren't going to show up in Trellis any time soon, but
> it's interesting to see how someone else has solved similar problems, and I
> definitely want to study this more.
>
> _______________________________________________
> PEAK mailing list
> PEAK at eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/peak
>



-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter