Book uses academic term "arity" without definition

[snej]

In the Compound Data Types chapter of the book, the term "arity" is used without any prior definition:

You can assign one tuple into another, if they have the same arity and contained types.

I've learned enough formal logic and programming language theory to know what "arity" means, but I suspect most programmers don't. (Neither does my spell checker!) And the book otherwise seems to be trying to use clear language and be readable by non-experts. I suggest changing it to:

You can assign one tuple into another, if they have the same number and type of items.

[kmcallister]

Sounds great to me, feel free to submit a pull request :) Maybe with "types" instead of "type".

[kmcallister]

Or:

You can assign one tuple into another, if the sequence of types in each is exactly the same.

[steveklabnik]

I'd prefer just defining arity. it's a really useful word.

[snej]

It's a useful word if you do a lot of functional programming or formal logic ;-), but the rest of the book is very informal and tries hard to make J. Random Scripter feel comfortable, so tossing in a $20 word seems out of place.

Maybe:

…if the sequence of types (their arity) is exactly the same.

[kmcallister]

But the arity refers to just the number of entries, not their types. It's an incomplete description and so awkward to define in passing.

[Gankra]

I don't think arity need be mentionned. Saying "contain the same types" seems sufficient. That already has to deal with (A, B) vs (B, A). Seems to me that also deals with (A, A) vs (A, A, A).

[steveklabnik]

@hartsantler it's not to show off fancy language, it's a computer science term. It's a good word for any programmer to know.

[ghost]

👍 for keeping arity somehow. It's well worth learning the word imho.

[kmcallister]

@hartsantler: This attitude is not going to serve you well in Rust. It's not "elitist" to define precise terms for concepts that may be hard to express in "plain english".

Of course one should define them in the text. And in this case I don't think it's worth the trouble, because there are satisfactory explanations in "plain english" (see above). So, I'm in agreement with you that the text needs to be changed. But turning it into a rant about "elites" is just gross and unhelpful.

The thing is... when people ignore your ideas while making fun of the words you use to express them, it really does breed bitterness and elitism, and ultimately a sort of siege mentality that you'll see in a lot of functional programming communities. It's not pretty, and I don't want Rust to go the same way, although I don't think it's particularly likely.

So please let's leave the culture war out of it. Technical writing is hard. There are always many tradeoffs. Just because someone uses a word you don't know, doesn't mean they're maliciously trying to feel superior to you. My unsolicited advice: Embrace being around people who know things you don't. Then you can learn from them. I hope that the Rust community will always be a safe place for that.

[mdinger]

Slight modification. I think signature is the right word. Even if signatures' definition is unclear, the example should make it's meaning understandable; something usage of arity lacked.

---

You can assign tuples onto each other if the signature matches:

let mut x = (1i32, 2i64);
let y =     (2i32, 3i64);
let fail =  (2i64, 5i32);

x = y;    // Works because signature is the same
x = fail; // Correct types, wrong order. This doesn't work.

---

[EDIT] Maybe too much in the rustbyexample style though...not sure.

[jxcl]

@steveklabnik The PR that addresses this ticket has been merged. Should this issue be closed now?

[steveklabnik]

Yes, thanks.