The Kind hierarchy may be modified at compile-time

Authoring Inform 7
1

WI 4.1 explicitly codifies the legality of modifying the kinds hierarchy with statements such as

A man is a kind of animal. A woman is a kind of animal. But this flexibility comes at a cost. The cost is that it’s impossible for the Standard Rules (or indeed any general purpose extension) to correctly handle modified kind hierarchies in all cases, and in many cases, NI can’t even handle them.

Here are three examples I’ve collected of NI failing to handle modified kind hierarchies:

A thing is a kind of direction. There is a room. Reported as bug 906, this causes an infinite regress of the same error over and over again.

A thing is a kind of room. Reported as bug 907, this causes an internal error.

[code]A room is a kind of door.

Foo is a room.
West of Foo is Bar.
West of Bar is Foo.[/code]Reported as bug 911, this causes two (identical) internal errors.

What really scares me, though, isn’t that NI breaks down in a few places. Rather, I’m disturbed that the above code is perfectly legal I7 according to WI. The problem is that we allow rearranging of the kind hierarchy after it’s been fully specified. When you’re allowed to do that, you can never ensure that your code will be correct, because someone might (for instance) reclassify your new kind of thing as a kind of door, or as a kind of container, or just about anything. Literally anything goes, as long as previous statements are not actually contradicted. I’ve never heard of any other language that allows rearranging the type hierarchy after it’s been specified. This is a dangerous misfeature and should be removed (or deprecated) from Inform in the next release.

At least, that’s my opinion. Does anyone want to offer contrasting views, or shall I file an umbrella bug now?

2

I’m not convinced that there’s actually a problem here. Most of the scenarios where this can cause problems under the Standard Rules are contrived and unlikely to come up in any real application, and it seems unrealistic to expect that user-created extensions can or should be prevented from making incompatible or mutually exclusive assumptions about the world model - especially in light of how bare-bones the default world model is.

3

It may be that the compiler can’t handle rearrangement of core types (thing, room, direction) because there’s wired-in code that builds relations on them. If that’s the case, this should certainly be excluded to avoid internal errors.

But, in general, an extension can always break your code by defining a term that conflicts with yours. Or removing a rule that your code relies on. Or saying “every turn: end the game.” I don’t think I7 has a strong enough notion of “correctness” to rule out kind redefinitions in particular.