[Feature Request] Add `contains`, `pop`, `dec` and more to macrocache

[EriKWDev]

Summary

In #11404 @jangko initially added some implementations for CacheTable.contains (and other functions) but they were removed from the PR. I couldn't find an issue mentioning them nor anything on the devel branch so I created this one. Feel free to close if already discussed elsewhere.

Description

I was in the process of converting some macros from using global {.compileTime.} variables to instead use macrocache for incremental compilation (especially wanting to use CacheTable), but found out I couldn't use string in cacheTable and others since there was no contains implementation.

Would be nice to have implementations like the ones found in Table but for CacheTable such as contains as well as other functions for CacheSeq corresponding to those for seq to ease development with macrocache.

Previously mentioned was:

• [ ] add CacheTable.contains
• [ ] add CacheSeq.contains
• [ ] add CacheSeq.pop
• [ ] add CacheSeq.find

I can also think of:

• [ ] add CacheCounter.dec like inc
• [ ] add '$'(): string for CacheCounter, CacheSeq and CacheTable for debugging

[metagn]

macrocache caches are supposedly meant to be only growable, meaning you can't have pop/dec. From what I understand you are supposed to just iterate over them once too, so other helper procs would add extra iterations that I'm not sure are supported.

[EriKWDev]

macrocache caches are supposedly meant to be only growable, meaning you can't have pop/dec.

I see. Would this prevent implementing ´contains´ for CacheTable as well? I don't know the details of the implementation, but supposedly that shouldn't cause an extra iteration?

[Vindaar]

I agree that (at least some of) these should be added.

Since I started using macrocache more, I always carry my own contains impl around (which is just a loop over the keys). The "only growable" part I understand and is fine by me.

Not sure I understand why iteration itself should be a problem (or if it is, then providing an items iterator seems broken).

[metagn]

I don't know the exact semantics, I was probably wrong about iterating multiple times. Currently macrocache just acts like a normal compile time global, so I don't know if anything that works now is supposed to work. (for example I do stuff like let key = table.len; table[$key] = node and I am not sure if it's supposed to work)

The original PR seemingly removed these procs because macrocache is supposed to be a low level module without any abstractions. The RFC mentions a typed wrapper without namespace strings around macrocache, so it might be better to try to do that first.

[Araq]

Please outline the pattern that you use contains for. I'm not against it, but we need to be careful that the data-structures remain "append-only" and what happens when there are races.

[Vindaar]

Please outline the pattern that you use contains for. I'm not against it, but we need to be careful that the data-structures remain "append-only" and what happens when there are races.

For me it's always a pattern as follows:

I have some macro that generates types, procedures or just some symbols. The macro cache is used to store these for the case of (these are all more or less related of course):

• either if the user calls the macro twice: in this case don't regenerate the same thing again. Both to avoid doing redundant work as well as to not generate two equivalent things with different names, which might lead to confusing errors.
• or in the case of macros that recursively look at input types / code and walk the tree to inspect it & again generate something. Sometimes this is a recursive macro on the implementation of certain symbols. If some symbol has already been processed, again no point in doing that again.
• or finally a case where the user needs to call some macro first to generate something. These "things" are stored in the cache to look them up from there, but also to provide a decent error message telling the user "hey, you forgot to call macro X for type Y!".

In all of these cases the macro logic depends on whether a key already exists or not.

I can provide explicit examples, if that helps. But the idea is always along these lines. a) avoid unnecessary computation and b) don't generate duplicate symbols.