|
From: Kevin K. <kev...@gm...> - 2017-05-30 04:10:05
|
Thanks to Donal's clarifications of the status of callframe management,
I've managed to get things to where all the demos pass, except for
four cases that throw errors. These appear to return subtly different
error dictionaries.
Accordingly, I've merged the 'kbk-callframe-motion' branch into
'dkf-callframe-impl', and closed the former branch. This merge also
picks up the fixes from 'kbk-callframe-fixes' that repaired the
endless loop on the 'mrtest' tests.
Next steps will have to be:
(1) If an 'invoke' is known not to affect the callframe at all
(many Core commands; all compiled procs until we understand
[upvar]), then change the sequence from
invoke intermediateStruct callframeIn command arg arg...
extractResult varOut intermediateStruct
extractCallframe callframeOut intermediateStruct
...
to
invoke varOut Nothing command arg arg ...
...
(all uses of callframeOut replaced by callframeIn)
(2) If, after this step, it is discovered that all 'return' and
'returnException' operations use the callframe pushed by the
'entry' operation. then it's unnecessary to push a callframe
at all. Change the entry from
entry callframeOut {literal {list of variable names}}
to just
entry {} Nothing
and replace all the uses of the callframe with Nothing.
This means that the following operations must all be prepared to
accept Nothing in place of a callframe as an input parameter:
entry - indicates that no callframe need be pushed
invoke - indicates that the target command does not use the
callframe. The type of the result is the return type
of the target command, without a result callframe.
result - The interpreter result should be the same irrespective
of whether a callframe is in use.
return - indicates that no callframe need be destroyed
returnCode - The return code in the interpreter should be the same
irrespective of whether a callframe is in use.
returnException - indicates that no callframe need be destroyed
returnOptions - The options dictionary in the interpreter should
be the same irrespective of whether a callframe is
in use.
It would be better to test for a zero data type code (or for NOTHING
as the text equivalent) rather than to look for the literal 'Nothing'.
If this introduces difficulties, it would be possible to introduce a
new opcode for any of these cases.
Let me know what would be easiest, and I'll code accordingly.
Once this is accomplished, the tests should buy back all their former
performance, and we'll have added callframe-dependent operations such
as [scan] and [regexp].
|