feat: All of the Awkward layout types.

[jpivarski]

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

[Moelf]

is this suppose to be Base.copy? I guess there's also Base.deepcopy() so it's one of them probably

[jpivarski]

It's supposed to be distinct from Base.copy. Layout nodes in Awkward each have a constructor named copy that shallow-copies every argument that is not named: it's a great way to get "a struct exactly like this_one but with this_field and that_field replaced."

Before the final version of this package, the name might change to something that doesn't sound like it's supposed to be Base.copy. Or if there's a Julia way of doing this, it would be replaced by that. (Note that this copy can change type parameters as well as values.)

[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

[jpivarski]

Note to self: if all Content subclasses implement zero, then it would be possible to auto-fill records and not require users to do something different when push_null! on option-type of record. That would be a good thing to do and this should become an issue.

[Moelf]

Congrats!! that was unbelievably fast

[jpivarski]

Thanks!

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