Suppose that I’m trying to create an achievement system. I might define an achievement kind like this:
An achievement is a kind of value.
An achievement can be achieved or unachieved. An achievement is usually unachieved.
An achievement has a number called the score. The score of an achievement is usually 1.
An achievement has some text called the description. The description of an achievement is usually “”.
But the compiler rejects the sentence “An achievement can be achieved or unachieved.” It tries to explain why with the following message:
Problem. The sentence ‘An achievement can be achieved or unachieved’ looked to me as if it might be trying to create an either/or property which would be held by all of the values of a rather large kind (an achievement). But this is a kind which is not allowed to have properties, because the storage requirements would be too difficult. For instance, scenes can have properties like this, but numbers can’t: that’s because there are only a few, named scenes, but there is an almost unlimited range of numbers. (That doesn’t mean you can’t create adjectives using ‘Definition: …’ - it’s only when storage would be needed that this limitation kicks in.)
But this fails to explain the problem. Instances of a kind defined with “An X is a kind of value” only come into existence when explicitly defined - it doesn’t make any sense for them to fall into the “just too many like numbers” group.
Further, the compiler is quick to contradict its claim that these kinds cannot have properties when the definition of the achieved/unachieved either/or property is removed leaving the other two properties:
An achievement is a kind of value.
An achievement has a number called the score. The score of an achievement is usually 1.
An achievement has some text called the description. The description of an achievement is usually “”.
That code is accepted, so at most “no properties allowed” means “no either/or properties” allowed.
And even the “no either/or properties allowed” rule falls when the definition of the achieved/unachieved property is re-added at a later point in the definitions of the new kind’s properties:
An achievement is a kind of value.
An achievement has a number called the score. The score of an achievement is usually 1.
An achievement has some text called the description. The description of an achievement is usually “”.
An achievement can be achieved or unachieved. An achievement is usually unachieved.
That code is also accepted.
The real problem was “the first defined property of a kind of value was an either/or property”.
But why isn’t that allowed?