A frob is a kind of thing.
A wibble is a frob with printed name "wobble".
Wubble is a frob.
Womble is a frob with printed name "H. Wimble III".
Dusty Expanse is a room.
"Scrawled in dust on the ground is '[list of frobs]'.
[line break]Scrawled below that is '[list of frobs in brace notation]'.
[line break]And one final line says '[list of frobs with indefinite articles]'."
As expected, the output of this is:
Scrawled in dust on the ground is "wobble, Wubble and H. Wimble III".
Scrawled below that is "{wobble, Wubble, H. Wimble III}".
And one final line says "a wobble, Wubble and H. Wimble III".
If you add A frob is always privately-named., this changes the first output to three frobs.
If you go back to the original and instead say A frob is a kind of object., the first output is entirely blank.
In all three cases the second and third outputs doesn’t change from the original (ie. they are as expected).
What I want is to declare these as a kind of object, and I was expecting “say list of frobs” to print the plain printed names (without articles or braces), as in the first example. Why does this behave differently, and is there some way to convince it not to?
I know that it’s possible to get the output that I want “manually”, eg. with:
To say frob-list:
let L be a list of texts;
repeat with item running through all frobs:
add printed name of item to L;
say L;
I’m just confused about this behaviour of list of frobs.
The object kind doesn’t have the publicly-named/privately-named property so kinds of objects are implicitly privately-named in this case. You can add the property to the new kind to make it behave the same way as things.
A frob can be privately-named or publicly-named.
A frob is usually publicly-named.
That’s irrelevant though. I actually want them to be privately-named, which they will be. The question is why list of frobs is behaving weirdly.
(For that matter I don’t see why list of X alters behaviour for privately-named things either; public/private naming controls whether the script name is registered for Understand or not, which doesn’t seem like it should have anything to do with a list of printed names – other than the printed name being initialised with the script name if not otherwise overridden, but that’s also independent of public naming.)
To say (L - list of objects) plainly: say L.
... [list of frobs plainly] ...
Somehow this is different and does produce the expected output in all cases, unlike [list of frobs]. Why, I don’t know.
(Or at least the extent that I can determine by looking at the I6 code, it appears that list of frobs does an inline objectloop and calls WriteListOfMarkedObjects, whereas all the ones that actually work appear to call LIST_OF_TY_Say on a list variable instead (which in turn appears to be constructed from a global linked-list not involving objectlooping). I don’t know why though, or why the former changes behaviour based on private naming / not being a thing. [And also that the I7 compiler isn’t smart enough to merge identical list construction routines together, though perhaps that happens later.])
Actually, it looks like what’s happening there is that To say list of (OS - description of objects) in the Standard Rules is what’s generating the “wrong” behaviour, whereas whatever I7 does naturally to lists absent such an overriding rule appears “correct”. Requiring it to be a list rather than a description “fixes” it, perhaps? Still seems weird to me.
I’m pretty sure this has to do with Inform’s treatment of indistinguishable things. If there is more than one thing (or object, I guess) with identical dictionary word entries, Inform assumes* that the player has no way to refer to one of them rather than the other, and so it will group them together in lists, refuse to disambiguate them, etc. That’s why if you write
A coin is a kind of thing. Lab is a room. There are five coins in Lab.
you will get “You can see five coins here” and when you “take coin” you will not be asked “Which do you mean, the coin, the coin, the coin, the coin, or the coin?” zarf explains that here.
So making the things/objects privately-named makes them indistinguishable to the parser, and that makes Inform assume the differences among them aren’t important, so–at least in some cases of the list-writer–it lists them as “three frobs” instead of giving their names. (Here is a place that I mention that this affects the list writer, though presumably somebody else told me that sometime–I can’t find where.)
A workaround is to give them internal names that the parser can understand. If the player can type an unobvious name like frob1 or frob2 and be understood, that’s usually not harmful to their experience! But whether this works would depend on the specific reason you want them to be privately-named.
*“assumes” because there are some cases involving understanding by relations where the player would be able to distinguish them, but this mechanic doesn’t catch those.
Ok, but then why does it print nothing at all when it’s a list of objects rather than things?
These are objects that keep track of something out of world (part of a menu system), so there’s no reason for the player to ever directly refer to them, which is why I don’t want any understanding names to clutter disambiguation (though they’re always nowhere so should never be in scope anyway).
If they’re out of scope, their names will never be checked at all, so they won’t clutter disambiguation. Making them publicly-named has no effect on parsing except for a small additional use of dictionary space. (Which doesn’t really affect parsing at all.)