`self' undefined inside functions, except if used in the calling SLiMEidosBlock scope

[grahamgower]

initialize() {
    initializeMutationRate(0);
    initializeMutationType("m1", 0.5, "f", 0);
    initializeGenomicElementType("g1", m1, 1.0);
    initializeGenomicElement(g1, 0, 1000-1);
    initializeRecombinationRate(0);
}

1 {
	//self;
	myfunc();
}

function (integer$)myfunc(void) {
	return self.id;
}

The above code produces this error with SLiM 3.3:

ERROR (EidosSymbolTable::_GetValue_RAW): undefined identifier self.

Error on script line 2, character 8 (inside runtime script block):

   return self.id;

But strangely, when the //self; line is uncommented, the code runs fine. I could understand if self were never available in the function scope, or if it were always available there, but being dependent on usage in the script block scope seems wrong.

[bhaller]

Ah, you have found a little quirk of the scoping policy. First of all, user-defined functions are an Eidos thing, not a SLiM thing, so they are not officially SLiMEidosScriptBlocks, and should not have self defined for themselves. So the function itself does not set up self, and that is correct. Second, variables that are defined in the calling scope are not visible in a called function, so if you were just trying to access x in the function and defining it x in the calling scope you would get an error, and that is correct. Third, SLiM-defined globals are not normal variables; they exist in the global scope. This is why sim and so forth are visible inside user-defined functions in SLiM; it's a special scoping hack that SLiM does. Fourth, self is a SLiM-defined global, so it follows those rules – it exists in the global scope and is visible inside called functions. So that also makes sense (arguably – this is all a bit strange and ad hoc, since it is SLiM hacking its way into Eidos without following all the rules). Fifth – and this is where the bug is – self and other SLiM globals are only set up by SLiM if the interpreter detects that they are being used. If you reference self in a SLiM script block, then self gets set up by SLiM; if you don't, SLiM doesn't bother setting it up. This is a good policy; it makes setting up the interpreter for callbacks much faster, since most callbacks don't use most of the pseudo-parameters that are officially defined for them. But your function references self, which SLiM is not smart enough to figure out means that self needs to be set up for the early() event. It ought to be defined and visible in your function, but it isn't because of SLiM's optimization of the variable setup.

So, yes, a bug. I'm not sure what exactly I would want to do to fix it; the Eidos/SLiM scoping rules are all a little bit ad hoc and really I'd like to eventually fix them to be more coherent. In any case, although this is technically a bug I don't imagine it is really getting in your way, is it? Is this causing any difficulties for you? If you need it fixed I can figure out a fix, but otherwise I'll probably just ignore this issue until such time as I revisit the scoping rules in SLiM 4.0 or whatever. :->

[grahamgower]

Thanks @bhaller. Yes, you should absolutely close this as "won't fix". Out of curiosity though, are there other global variables with the same behaviour?

[bhaller]

All callback pseudo-parameters, I think. They're listed in chapter 24. I'll keep the issue open for now; there is a bug here, and it's a good reminder to think more about scoping some day.