[ANN]: ZeroDimensionalArrays.jl: zero-dimensional arrays/references/boxes

[nsajko]

@Tortar

I have to say that I also find the name of the package itself a bit confusing, specifically: Why the package is named ZeroDimensionalArrays.jl if the main use case is boxing fields?

Boxing is merely one of the uses, see the examples in the readme. Two of the three types, the ones whose names currently start with Box* prefix, box their only element, due to being defined with mutable struct. In contrast, the third type, ZeroDimArray, is defined with struct, not with mutable struct, so it doesn’t do boxing.

Will try to make this more clear in the readme again.

@Tortar

something like e.g. BoxedVals.jl seems better to me. Besides that, why the struct version is called ZeroDimArray while all the rest refers to boxes? Isn’t there a way to uniformize a bit more the naming?

A name such as BoxedVals.jl would only cover two of the three exported types, as just explained.

@mcabbott

I’m not sure why there are 3 different cases at all.

For performance mostly:

• Use ZeroDimArray to avoid the overhead of a mutable struct, when a mutable struct is not required.
• Use BoxConst (that’s the current name at least) to:
  • forbid mutation
  • reap the benefits from letting the compiler know there can’t be any mutation, such as better inferred effects, to enable constant folding

Will try to add something to that effect to the readme, or make it more clear.

@mcabbott

I had to look at the source to see what “BoxConst * declared with mutable struct” means. What’s that even for?

Just addressed this immediately above.

@mcabbott

For fields, clearly abstract mutable_int::Ref{Int} is bad, but isn’t the right pattern for some mutable fields to have mutable struct with const immutable_bool::Bool? Why is this better?

Sometimes one just needs a reference to accomplish the goal, that is, access performance is not the only important thing. I’ll quote @foobar_lv2 from two days ago:

@foobar_lv2

Why would you put a Ref into an immutable struct? Obviously because your program logic wants to put references to the same shared mutable state into many different immutable structs, duh! Same reason why you would put any mutable struct into an immutable one.

That’s eminently sensible.

It’s possible I haven’t ever written code like that, but the idea is, if it’s not clear, that there’s some data structure one wants to implement, one needs references to implement this data structure, and either:

• needs to forbid mutation for safety
• wants to let the compiler know there’s no mutation to enable the compiler optimizer more

Will also try to explain this better in the readme, however I’m afraid it’s becoming too big, possibly causing some to avoid reading it. It’s possibly already bigger than the source code. Perhaps it just needs better structure?