- A Change in Convention
- Some Words About Ambiguity
- Back to Business
- Strings
- Arrays
- Hashes
- Ranges
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Some Words About Ambiguity
Since we seem to be approaching the craft of programming from a more linguistic than mathematical perspective, we would do well to consider the problem of ambiguity. In general, computer languages cannot tolerate ambiguity, yet in everyday speech we put up with it all the time and make the best guesses we can.
What conclusion do we come to when we hear that "Maria was stung by a bee in a purple bathrobe"? There are two ways to interpret the sentence. We as experienced listeners have a reasonable expectation that people are more likely to wear bathrobes than bees are, which helps us get the interpretation right. But when a listener has no domain knowledge, or understanding of the universe that the sentence is talking about, it is necessary to clear up the ambiguity, possibly by rearranging the words.
Although it isn't quite proper English, we can use parentheses to remove the ambiguity just as effectively without changing the word sequence.
When reading either of these, we have to decide what the parenthesized phrase is talking about before we can relate it to the rest of the sentence. Sentence A makes it quite clear that the bee was in the bathrobe when it stung Maria. But in sentence B, even though the bee is the active party, Maria is the subject of the parenthesized phrase. Put another way, the words between the parentheses "evaluate" to a rather sore and angry Maria, and thus it is Maria who wears the bathrobe.
Programmers, at least when relatively inexperienced, shouldn't assume that an ambiguous expression will be interpreted in the intended way. The Ruby interpreter has no domain knowledge to rely on; what it has instead are precedence (or grouping) rules, which may or may not always follow your intuition but are always applied consistently.
We could learn the rules right now if we wanted to, and always try to remember them when writing scripts. Knowing the rules would let us arrange our code in a way that makes it behave as we intend. But that sounds too much like work. For now at least, it will suffice to know that, when in doubt, you can clarify your meaning by grouping expressions with parentheses.
The last exercise of Day 2 is a case in which you need to parenthesize or the interpreter will get your meaning wrong. In the next example it gets it right, so unless you really are wondering what class nil belongs to, you can leave off the parentheses.
print [1, 2, 3].type #–> prints "Array" and returns nil print ([1, 2, 3].type) #–> prints "Array" and returns nil (print [1, 2, 3]).type #–> prints "123" and returns "nilClass"