[PEAK] recursion limit

nicky van foreest vanforeest at gmail.com
Sat Jul 16 16:43:23 EDT 2011

HI Philip,

Thanks for your explanations.

> Ok, confirmed at 100, and switching the 'compute' attrs to 'maintain' attrs
> makes it go away, even up to 10000.

Here it also works at 10000 too, but it becomes noticebly slow.
However, this is as expected, given the amount of work.

> Cell objects have a level attribute that's used to indicate their distance
> from a dependency graph root; is that what you're asking about?


>>  Second, I would like to have a
>> program/parser that figures out by itself the dependency graph of the
>> attributes and functions. Now I have to make explicit the
>> trellis.attrs and the trellis.compute.attrs/trellis.maintain.attrs,
>> which I would prefer not to do by hand, but let the computer figure it
>> out. Why is this is not implemented in trellis? (I must admit that I
>> don't quite know how to do this; it is just a question out of
>> interest.)
> I don't understand what feature you're asking for here.  The distinction
> between compute, maintain, and attrs is part of the design of your program,
> not something that a parser can figure out.  By stating that something is a
> maintained value, it means that it may have side-effects and also that it
> should be able to access the previously computed value.  By saying it's
> computed, you are saying there are no side-effects to the computation and
> that it should only be calculated as needed.  Otherwise, it is just an
> observable variable.

Ok. I did not understand this distinction well enough up to now, at
least not in the sense that this distinction can (and should) be used
as a part of the design of a program.


More information about the PEAK mailing list