Unexpected behaviour of options

[zickgraf]

Consider the following piece of code:

myfunc1 := function( )
	Display( ValueOption( "myopt" ) );
	return 1;
end;

myfunc2 := function( )
	return IdFunc( myfunc1( ) : myopt := "myopt_value" );
end;

x := myfunc2( );
x := IdFunc( myfunc1( ) : myopt := "myopt_value" );

Observed behaviour

The output is:

myopt_value
fail

Expected behaviour

I would expect the output to be

fail
fail

(or at least the same output in both lines) because I do not see a reason why the option should propagate into the call of myfunc1 in the first case but not in the second.

Copy and paste GAP banner (to tell us about your setup)

 ┌───────┐   GAP 4.12dev-1020-g1fe30f7 built on 2021-08-19 10:21:04+0200
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: x86_64-pc-linux-gnu-default64-kv8
 Configuration:  gmp 6.2.1, GASMAN, readline
 Loading the library and packages ...
 Packages:   Browse 1.8.9, GAPDoc 1.dev, IO 4.7.0dev, PrimGrp 3.4.0, SmallGrp 1.4.1, TransGrp 2.0.5
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'

Also happens with GAP 4.11.1.

[fingolfin]

Good catch. This is due to how options are handled in the immediate interpreter (used in your second call) vs. the "executor": The former immediately executes code as it encounters it, so it first executes the call myfunc1( ) before even seeing the option.

But for the executor, first we "compile" the function into a bunch of statements (or expressions; for simplicity, I'll just always say "statement). And function calls involving options are handled in a somewhat peculiar way: they are encoded as STAT_PROCCALL_OPTS resp. EXPR_FUNCCALL_OPTS statements. But these simply wrap a regular call statement such as EXPR_FUNCCALL_3ARGS or STAT_PROCCALL_2ARGS.

Now here's the problem: the arguments to the function are evaluated by the handlers for EXPR_FUNCCALL_3ARGS etc.; but the handlers for the *CALL_OPTS statements invoke those handlers; so they only can set the options before invoking those handlers, and hence before the arguments are evaluated.

To fix this, we need to revise how options are handled, and ensure this happens after the arguments are evaluated, but before the actual function call.

[fingolfin]

@zickgraf see PR #4632

[zickgraf]

Thanks for the explanation and the quick fix! I can confirm that my original issue does not occur anymore when using the PR :-)