feat: All of the Awkward layout types.

[jpivarski]

• [x] PrimitiveArray (is LeafType)
• [x] EmptyArray (is LeafType)
• [x] ListOffsetArray (is ListType)
• [x] ListArray (is ListType)
• [x] RegularArray (is ListType)
• [x] IndexedArray
• [x] IndexedOptionArray (is OptionType)
• [x] ByteMaskedArray (is OptionType)
• [x] BitMaskedArray (is OptionType)
• [x] UnmaskedArray (is OptionType)
• [x] RecordArray and AwkwardArray.Record
• [x] TupleArray and AwkwardArray.Tuple
• [x] UnionArray

[Moelf]

Is there a conceptual or application-wise difference between Unset and built-in singleton type nothing::Nothing?

[jpivarski]

In Awkward, IndexedOptionArray satisfies both is_indexed and is_option, which I'm implementing here with abstract types (isa-checkable interfaces; no data or constructors). But it seems that multiple inheritance of abstract types is not yet a feature of the language (JuliaLang/julia#5).

So I'll just ignore is_indexed and only implement is_option, so that the inheritance is strictly a tree. It's a minor point; just noting this for the record.

[jpivarski]

Is there a conceptual or application-wise difference between Unset and built-in singleton type nothing::Nothing?

Some of the arguments for copy could legitimately be nothing::Nothing. Let me think of an example... Actually, no! RecordArray.fields would have been the example (in Python, fields=None means it's a tuple with unnamed fields, rather than a record with named fields), but in Julia, I'm using a NamedTuple to provide both field names and contents. On the one hand, that means that there happen to be no Content subclass arguments that could take a None/nothing value, and on the other hand, it means that I'm not done with RecordArray because I'll need to implement tuples as a separate class, based on Tuple, rather than NamedTuple.

But even if I switch all of the Unset sentinels over to Nothing, there's a (small) chance that in the future, a parameter will be added that can legitimately be nothing, and then it would be hard to switch all the Nothings back into Unset. It would break backward compatibility.

The reason is completely analogous to why these methods in Python have UNSET defaults, rather than None:

https://github.com/scikit-hep/awkward/blob/0accfadd25d6562813e91771177bb5b0bda5a7b1/src/awkward/contents/indexedarray.py#L135-L140

[Moelf]

Congrats!! that was unbelievably fast

[jpivarski]

Thanks!

Some things will be easier to apply, now that all of the node types exist.