Rename "tuple" to "record"

[njordhov]

The Clarity concept of a tuple refers to a collection of key/value pairs, generally known as an associative array. This data structure has many names across programming languages.

Calling this data structure for tuple is unusual, perhaps borrowed from Python named tuples. The tuple concept should be renamed to a more familiar term, such as struct or dict.

Lisp languages such as Clojure regularly refer to key/value collections as maps but this term can be confusing when there also is a map function, and is better avoided.

[jcnelson]

Tuples in Clarity are finite typed ordered sequences of key/value pairs. They are not associative arrays.

[njordhov]

They are not associative arrays.

Sure, being immutable typed data structures they're not implementing the full functionality of associative arrays. Referring to them as tuples won't clarify this limitation for most developers.

Besides, the proposal is not about renaming them to associative arrays. What's the implication of your point for the naming of the concept?

Tuples in Clarity are finite typed ordered sequences of key/value pairs.

Is the order actually maintained in the btree representation?

[jcnelson]

I'm saying that tuple is the appropriate word. They are not, and have never been meant to be, associative arrays. You cannot add or remove pairs from a tuple, for example (but per the link you shared, you can with an associative array). Your characterization of Clarity's concept of a tuple as a collection of key/value pairs, generally known as an associative array is incorrect.

[jcnelson]

Is the order actually maintained in the btree representation?

Yes. The order of the types of key/value pairs is not only maintained in the btree representation, but also, is part of the tuple's type signature.

[njordhov]

I'm saying that tuple is the appropriate word.

Better use a familiar name for a similar datastructure and describe it as immutable.

This would be a good time to check with prospective Clarity developers what makes sense to them, rather than being stuck with confusing terminology.

[jcnelson]

I think you are confused.

First, variables in Clarity are immutable already -- once assigned a value via a let-binding, they cannot be re-assigned anywhere within the let-binding's expression. For example, this does not type-check:

(begin
    (let ((foo 1)) 
        (let ((foo 2)) 
            (begin 
                (print foo)))))

Second, a tuple by definition has a product type, which fixes both its length and the sequence of types of its components. You cannot insert, reorder, or delete key/value pairs within a tuple, because doing so would change its type. This is true in most programming languages, including Python.

Third, in most programming languages (but not Clarity), you can mutate the value of a tuple. For example, in Rust, if I have a tuple let mut x = (1u64, true), the operation x.0 += 1 is allowed, but there are no legal operations that would let me assign x to (1u64, 2u64, true) (since x's type signature is (u64, bool)).

[njordhov]

I think you are confused.

You may have missed that I referred to immutable datastructures rather than symbol bindings. Anyway, your points are irrelevant to the argument:

Instead of using the confusing term tuple for such composite key/value datastructures, better use a more familiar term such as record or struct, and describe it as immutable.

[njordhov]

Tuples in Clarity are finite typed ordered sequences of key/value pairs.

Clarity tuples don't have the expected properties:

1. Per definition, the elements of a tuple don't have to be distinct. In contrast, key names may not appear multiple times in the same Clarity tuple form:

(tuple (a 1) (a 1))   ;; Not a valid Clarity tuple

2. Per definition, the order of tuple elements is significant. In contrast, element order is ignored in Clarity:

   (tuple (a 1) (b u2))
   (tuple (b u2) (a 1))  ;; same
   (tuple (a int) (b uint))  ;;  type for both tuples

They aren't actually tuples but unordered collections of labeled data values.

[jcnelson]

Per definition, the elements of a tuple don't have to be distinct. In contrast, key names may not appear multiple times in the same Clarity tuple form:

This doesn't change the fact that Clarity tuples have product types, which is the distinguishing property of a tuple as compared to an associative array. EDIT: I did see that you said above that you're not proposing we rename them to associative arrays. I'm emphasizing this point again in this comment, because I want to make it clear that Clarity tuples are not structs or dicts either (and I see struct and dict as having meanings closer to "associative array" than "tuple"). "Immutable associative array" is a no-go as well.

Now, I'm open to referring to Clarity tuples as records since this is more accurate -- i.e. we're labeling each component type, and the label is part of the type signature. But records are not associative arrays either -- a record still has a product type.

Per definition, the order of tuple elements is significant. In contrast, element order is ignored in Clarity:

Yes; I retract what I said earlier. Clarity will internally impose an ordering on the components of a tuple in order to efficiently type-check them, but I had forgotten that this is not visible to the programmer.

This would be a good time to check with prospective Clarity developers what makes sense to them, rather than being stuck with confusing terminology.

I think we should use the most accurate PL terminology, so there's no ambiguity as to what each Clarity object is and what operations may (or may not) be performed on it. That said, I'm renaming this issue to ask if "record" is more appropriate than "tuple". I'm a hard "no" on calling tuples anything that might give the developer the impression that these things are associative arrays -- not only are there no mutation operations defined on Clarity tuples, but also the label is part of the type definition (i.e. it's not a Clarity value).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed. Please reopen if needed.