Combining ideas with ContextManagers.jl

[c42f]

@tkf we discussed just a little about the differences between ResourceContexts vs ContextManagers in https://github.com/c42f/ResourceContexts.jl/pull/8

If you're interested I'd like to discuss the design pros and cons a bit and see whether we can have a package with the best of both approaches.

Here's few design goals I currently have for this kind of thing

1. API when using resources — ideally
   1. Minimal syntax; "avoid breaking function composition" — I feel for a technical computing audience, resource management is an annoying but necessary distraction from the main code paths in the program. I want to compose functions, even if some functions in the composition chain need resource management. The ! syntax is interesting for this.
   2. Make it inconvenient to leak resources by mistake. (Not a design goal to make leaks impossible, just annoying :-D)
   3. Allow resources to be available for hacking in the REPL, while also not leaking them when references to them are lost.
2. API when defining resources / cleanup code
   1. Neat API for defining ad-hoc resource cleanup.
   2. Expressivity: cover anything you could express with a do block? Eg try-catch-finally.
   3. Compositionality of resources: It should be possible to define things like ContextManagers.SharedResource (I guess!)
3. Efficiency
   1. For a fully general solution it kind of needs to be zero cost in "most use cases".

Do these seem like fitting goals for Julia? Are there important aspects I've missed?

---

For resource usage, ResourceContexts does reasonably well - it mostly succeeds in (1.i), though I don't really like the rules for the @context macro. @context could be improved by putting it at outer scope and figuring out acceptable scoping rules for each language construct. This would be necessary if ! syntax ever become a language construct. I think ResourceContexts succeeds in (1.ii). For (1.iii) it somewhat succeeds, but resources are leaked to the global context which isn't cleaned up until session exit.

For definition of resources, ResourceContexts is very good at (2.i). It currently fails at (2.ii) because there's no notion of catch block. I think it also fails at (2.iii), though I'm not 100% sure :-)

For efficiency ResourceContexts is currently quite bad because it uses a mutable boxed set of closures (yikes!) See #4 for some thoughts. As a language feature I feel it could be optimized to be zero cost provided @defer uses are inlined into their @context and loops introduce a @context scope.

---

Having written all this, I feel the second half the API difficulties mostly reduce to the general problem of writing state machines in a neat way. The context-passing approach of ResourceContexts is one way to get around that which simultaneously helps with (1.ii). (I guess it would be fair to say that ResourceContexts currently "reifies cleanup continuations as a list of boxed closures" :laughing: :sweat_smile: ? )