Breaking changes for SLiM 4.0

[bhaller]

So, I've started thinking about SLiM 4.0. The big thing will be moving forward with the "multispecies SLiM" design that I've been pondering for a while now. However, moving to a new major release (4.0) will be an excuse to break a few things that bother me about the design of SLiM. I don't want to break BIG stuff; people should not have to totally rewrite their models, backward compatibility is important. I'm looking for small things that have often been a source of confusion, or are just generally ugly, that could be smoothed out with only minor, easily fixed breakage with a nice helpful error message. My ideas so far:

• Leaving out early() and having an event like 1 { ... } be an early event by default should be removed. It is not hard to just write early(), and the existence of a default is just confusing. It got worse when we introduced nonWF models (since early() and late() kind of play opposite roles in some ways, but the default is early() for both model types), and it got worse again with the addition of first() events since now, with three different event types, it feel even more arbitrary for one of them to be the "default".

• I'd like to clear out redundant pseudo-parameters to various callbacks. The class Individual didn't exist for a long time in SLiM (it's hard to even imagine that now!), and so callbacks had pseudo-parameters that gave information about the focal individual: genome1 and genome2 and childIsFemale and subpop and so forth. All of these are now unnecessary, because pseudo-parameters have been added for the focal individual(s) of each callback type; you can just do individual.genome1 or whatever, and that is probably actually faster than setting up the pseudo-parameter for the callback is (but I should time that). Now these excess pseudo-parameters just clutter up the APIs and slow down the setup/teardown for the callbacks.

Nominations are welcome; @petrelharp, @grahamgower, @rdinnager, @bryce-carson, @bodkan, others, any ideas? I don't promise to do things that are nominated, but I'd definitely like to hear any suggestions you have!

[petrelharp]

It is not hard to just write early(), and the existence of a default is just confusing.

I agree! I can never remember when the default is. (Of course, I can never remember quite when early() is, either.) Oh! Here's a suggestion - have an option up in Help that pops up a diagram of the life cycle for the current model type!

I'll think about other things...

[bryce-carson]

What about improvements to ploidy?

I looked at modelling hymenopterans, which SLiM is capable of modelling, but it is difficult to do correctly, and there is only a script in SLiM-Extras at the moment.

The documentation could be expounded, or methods for adding and removing chromosomes to an individual could extend the concept of (and API related to) NULL chromosomes.

[bhaller]

What about improvements to ploidy?

That's most definitely on my radar as an area for improvement (although an immensely complex one that I don't really understand). But what I'm looking for here are warts in the existing design of SLiM that require a break with backward compatibility to fix, not new feature requests. :->

[bryce-carson]

The documentation could be expounded, or methods for adding and removing chromosomes to an individual could extend the concept of (and API related to) NULL chromosomes.

I stand corrected, there were changes to modelling ploidy, and a manual update specifically related to haplodiploidy, in SLiM 3.7 I had missed. I just read a little of #251 and took a look at the updated manual. 😸

I suppose the last time I was looking at this was before SLiM 3.7 and I assumed nothing had changed!

[bhaller]

The documentation could be expounded, or methods for adding and removing chromosomes to an individual could extend the concept of (and API related to) NULL chromosomes.

I stand corrected, there were changes to modelling ploidy, and a manual update specifically related to haplodiploidy, in SLiM 3.7 I had missed. I just read a little of #251 and took a look at the updated manual. 😸

I suppose the last time I was looking at this was before SLiM 3.7 and I assumed nothing had changed!

Oh, sorry, yes – I thought you were talking about modeling polyploidy, and missed the reference to hymenopterans. Yes, modeling of things like haplodiploidy was greatly improved in 3.7, and there is now a nice example of haplodiploidy in the manual. I'm actually pretty happy with how it works now. Polyploidy remains difficult at best, though.

[bhaller]

OK, all of the ideas above (well, not polyploidy :->) are now in the multispecies branch on GitHub, including your idea @petrelharp of showing the generation cycle diagrams in SLiMgui (try the new Help menu items). I'm going to close this now, but if anybody has any other ideas for API changes for SLiM 4 that would break backward compatibility, now is the time; feel free to log a new issue!