I don’t want to break the flow of the other thread, but this is the absolute worst when it happens. It’s gotten to the point where I have a bit of code I always include in a new project.
%% A sanity check: typo objects like #palyer will end up creating new objects that are not in any room, and this will catch them
(startup)
(exhaust) {
*(object $Obj)
~(direction $Obj)
~(relation $Obj)
~(supposed to be nowhere $Obj)
~(room $Obj)
~($Obj is in room $)
~(attracted by something $Obj)
(div @error) { WARNING: $Obj \( (the $Obj) \) is nowhere! }
}
%% The interface for ($ attracts $) needs the first parameter to be bound
(attracted by something $Obj)
*(object $Parent)
($Parent attracts $Obj)
In Dialog, you create an object by mentioning it in any context. But if you create an object unintentionally with a typo, it’ll probably end up nowhere.
So, this checks for objects that are nowhere and aren’t supposed to be. It means you have to use (supposed to be nowhere $) to flag things that are supposed to be nowhere, but it’s a small price to pay in the end. You don’t want to know how many times during Stage Fright development I accidentally called Gus #a-lamp instead of #a-dark![1]
Maybe at some point I’ll clean this up and PR it as start of the standard library. It’s saved me more times than I can count by now.
I started coding before Ada and Sarah were done writing, so the characters are all named #a- followed by a one-word description of their puzzle. I didn’t get the names until a few days later. ↩︎
It’s honestly happened to me so many times I’ve considered adding a (manually-enablable) warning to the compiler that warns if an object is used but doesn’t appear as a topic (appearing in the leftmost column). For now, this works well enough that I haven’t.
For objects, being able to use them without defining them first is a bad design imho.
For global state, I’m more on the fence about it, but tend to think that requiring a definition is reasonable (not a big imposition on the programmer).
Yeah, one of the design ideals of Dialog is that as much as possible should Just Work without extra boilerplate, but sometimes its “handle everything automatically” ethos gets in the way.
Unfortunately, it’s very hard to actually detect which objects are declared as topics and which aren’t, because the compiler literally doesn’t have a struct for an object! The “program” struct has an array of dictionary words that are the object identifiers, and that’s it. When Dialog says an object is just an identifier, it means it!
That said, the dictionary word struct has some room for flags, so I could add a flag there. That would be the cleanest solution. Would people find this feature useful?
Yes, an object name that’s not used as a topic should be a warning by default.
Yes-ish. It shouldn’t be a warning by default, but there should be an option to warn about it.
No, this would not be a useful feature. Don’t spend time on it.
There seems to be a strong consensus here! Once the Iron ChIF pilot is over, I’ll add a warning for objects that never appear as topics. There will be a command-line option to disable this warning, and it won’t appear for anything with less than 100 total lines of code (generally meaning small test examples—this is the same rule for warning about missing metadata).
I don’t think the 100 line minimum makes sense for a check that looks for issues in what the code actually does. Surely you would want small test examples to work as well?
My thinking there is that the current behavior—create objects by mentioning them—is probably desired in smaller examples or programs that don’t use the standard library, while the new behavior—require explicit declaration of each object—is desired for full-fledged IF projects.
I could also tie it to the presence of a library file, if that would be a better heuristic. But a lot of the language examples in the manual use objects for non-IF purposes (like making a list to filter) and adding declarations to all of those would be a hassle.