On Sun, Dec 24, 2023 at 08:16:46PM +0800, Qian Yun wrote:
> OK, this might not be that complicated after all, hear my analysis:
> 
> 1. Assume there is only 1 (global) scope for $timedNameStack,
> and it is only modified by push or pop, never gets assignment.
> 
> When an exception is thrown in somewhere and catched somewhere else,
> now there's a "stopTimingProcess A", but the head of $timedNameStack
> is B.  We can simply attribute the stats to A, and continue.
> (Current "savedTimerStack" is attributing the stats to B.)
> 
> The only downside is that $timedNameStack will grow indefinitely.
> 
> 2. Now let's have a dynamic scope for $timedNameStack for each nested
> "processInteractive".  Problem solved.  No need to wrap around every
> CATCH.  $timedNameStack will not grow indefinitely.
> 
> 
> What I'm saying is:
> 
> 1. dynamic scoping for $timedNameStack
> 2. do not use savedTimerStack around CATCH
> 3. do not check with "peekTimedName" in "stopTimingProcess".
> (aka allow unbalanced $timedNameStack, which is a price has to be paid
> for exception handling)

I think that this would be a regression.  Most cases of unwinding
probably happens in a single invocation of interpreter and now
AFAICS they work fine.

AFAICS main thing is deciding which interpreter calls should use
"unified" timing (that is timing context from outside) and which
should use new timing context.  ')read' should use new timing
context and for this dynamic '$timedNameStack' probably is fine.
IMO 'interpret' calls from algebra should use unified timing
context, that is skip 'initializeTimedNames' or arrange things
so that 'initializeTimedNames' do not create new context.

'interpret_block' and various 'eval...' functions probably should
be treated as 'interpret'.

-- 
                              Waldek Hebisch

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/ZYmeN8YNZXRln3_u%40fricas.org.

Reply via email to