Re: [tclquadcode] Data motion to/from callframes

[Donal K. F. <don...@ma...>]

On 30 May 2017 5:09 a.m., Kevin Kenny <kev...@gm...> wrote:
> 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

I could also detect that the expected result type of the opcode doesn't contain CALLFRAME and use that. 

>     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.

I will definitely need to detect that. For consistency, the callframe parameter needs to be supplied in a form that can be detected as being not-a-callframe. (A nothing value/type is fine.) 

>     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.

Again, it is a matter of detecting the situation and issuing the other implementation. Not a big deal. 

> 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.

I think I will just hand that out to a new custom Tcl function that takes the value in the quadcode and returns whether it is a callframe. That can do whatever smart thing is required, and is easy for you to adjust to be what suits. 

Overall, it seems like a good plan. 

Donal.