That code makes me feel like the prettiest one at the ball!
2 Likes
That code makes the “privately-named” plan look awfully easy. :)
3 Likes
Fair point.
Unless you have a large number of objects (to expunge plurals from) that you can now loop through :)
1 Like
Seems like the default plural is always the second entry, so with a few small crimes against readability:
to remove default kind-name plurals: (- objectloop(({-my:0} provides name) &&
({-my:0}.#name > WORDSIZE) &&
((({-my:0}.&name-->1)->#dict_par1) & 4))
{-my:0}.&name-->1 = {-my:0}.&name-->0; -)
when play begins: remove default kind-name plurals.
Also, one will want to up DICT_WORD_SIZE to at least 10 or get some odd behavior with direction, container, and supporter.
1 Like
Sadly, this is not the case (as uncommenting the print statements in my example will demonstrate).
EDIT: it’s usually the LAST entry in the name property array. So try this:
to remove default kind-name plurals: (- objectloop(({-my:0} provides name) &&
({-my:0}.#name > WORDSIZE) &&
((({-my:0}.&name-->({-my:0}.#name/WORDSIZE-1))->#dict_par1) & 4))
{-my:0}.&name-->({-my:0}.#name/WORDSIZE-1) = {-my:0}.&name-->0; -)
EDIT2: built-in (but not author-defined) directions (inevitably) are an exception, in that the pseudo-plural is the SECOND entry (or SECOND-to-last) entry in a 3-name array: e.g. with name 'north' 'direction' 'n',, so ‘direction’ won’t be removed by the above code on 2 counts- firstly because it’s not flagged in the dictionary as a plural; secondly because the pseudo-plural is not the last name in the name property array
2 Likes
The weird thing with instances of directions, supporters and containers is that the default-plural-name-of-kind compiled to their name property is ‘direction’, ‘supporter’ and ‘container’ respectively, none of which are flagged in the dictionary as plural words (because the true plural forms ‘directions’ etc. exceed the standard 9-character dictionary word-length limit).
This means that neither my nor Zed’s code as written (which depend on replacing plural-tagged entries in the name property) will remove these ‘spurious’ plural names from instances of directions, supporters or containers. i.e. even after ‘depluralising’ you can still type ‘take containers’ (effectively truncated by the parser to ‘take container’) and take a container in scope, or type ‘take every container’ to take all of them.
I presume the same issue would apply to any author-defined kinds with a kind name 9 characters or more in length.
EDIT: confirmed that this is the case: in my example, if the plural of breakfast is not redefined as porridges, then a non-plurally-tagged breakfast is inserted to the name properties of all instances of the kind ‘breakfast’.
If this goes in an extension, I think it would be worth redefining the plural names to get around this issue: make them be “dirs”, “conts”, and “supps” or whatever, and then the plural-nuking code can remove them as usual.
1 Like
Or, if not compiling for z-code, do as Zed suggests and
Use DICT_WORD_SIZE of 10. [or some value higher than 10]
If the author has added “understand” statements, those will be after the default plural. But I drew a very silly conclusion from testing things with single-word object names. So:
Include (-
[ RemoveKindPlurals o i;
objectloop(o provides name && (o.#name > WORDSIZE))
for (i = 1 : i < o.#name/WORDSIZE : i++ )
if (((o.&name-->i)->#dict_par1) & 4) {
o.&name-->i = o.&name-->0;
break;
}
];
-)
Here’s another wrinkle: look what happen with player's holdall:
with name 'backpack' 'player^s//p' 'holdalls//p'
For the holdall’s multiple-word self, you get two automatically-created kind-name plurals.
The thing I said last year works, too.
But on balance this “overwrite plurals with a second copy of the first word” approach or “turn the plural into something the parser won’t accept” are so kludgey they make either of making everything privately-named or post-processing the I6 before compiling it look good in comparison.
perl -pi.bkp -e $'s{\'(directions|things|people|rooms|doors|containers|supporters|devices|vehicles|men|women|animals|backdrops|regions|player\\^s|holdalls)//p\';?}{}g' auto.inf
Of course, the best solution would probably be an option like “use no automatic plural names”. I just have to figure out the guts of the compiler well enough to know how to do that.
I think there’s room for disagreement here.
Adding a post-processing and separate compilation step where you also have to maintain an accurate parallel list of kind name plurals doesn’t seem like an author-friendly advance on automatically replacing all auto-generated plurals, which simply works in a fire-and-forget fashion with minimal included code. It will also take 'player^s//p' 'holdalls//p' in its stride as long as you don’t break out of the loop with the first replacement (as in my originally-posted code) and it will also happily ignore any plurals added via “Understand…”, which are incorporated into the routine called by the parse_name property rather than added to the name property. If you want to just do it with certain objects, just define an either-or property (e.g. An object can be non-plural) and include a filter for that property in your objectloop condition, so you can just write the baboon is a non-plural animal to strip ‘animals’ from the baboon’s names, or an animal is usually non-plural and so on.
Making things privately-named and providing a separate “Understand…” phrase to reinstate the list of name words you’ve just sacrificed isn’t a chore if you only feel the need to do it for a few objects. But to do it for EVERY object you write is a real pain.
So, I guess you pays your money and you takes your choice of the approach that works for you and your situation 
I wouldn’t claim that adding an extra compilation step is friendly to IDE-users. My perl one-liner was just a demo of the concept. Certainly, a more sophisticated post-processor that actually looked at kind definitions within the I6 would be desired for real-world use. The former I could whip up easily enough for an IntFiction post; the latter not so much.
Indeed!
After far too much time, I found where one can deactivate it.
https://ganelson.github.io/inform/runtime-module/7-np.html#SP4
if (from_kind)
LOOP_THROUGH_WORDING(j, PW) {
int additional = TRUE;
LOOP_THROUGH_WORDING(k, W)
if (compare_word(j, Lexer::word(k)))
additional = FALSE;
if (additional) {
TEMPORARY_TEXT(content)
WRITE_TO(content, "%w", Lexer::word_text(j));
EmitArrays::plural_dword_entry(content); entry_count++;
DISCARD_TEXT(content)
}
}
I just commented out the inner if-statement, but it looks a lot like commenting out the whole thing would be fine. (This is a blunt tool and far from having a switch within I7, of course)
3 Likes
Aha! There it is!
To add a new use option to control it, it looks like the main thing is in Compilation Settings—which is where I’m learning for the first time that “use the serial comma” is built into the compiler rather than just part of Basic Inform or the Standard Rules, which seems absolutely bizarre to me from an architectural perspective.
We’d want to add a new entry to the compilation_settings struct, and then we can read the value from global_compilation_settings in that if-statement you found.
This seems like a relatively straightforward change to make, all things considered. Think it’s worth trying to make a PR? I don’t know if Graham accepts those at this point.
(I did build Inform from source, so I could try making the change in my version at least, but the convenience of it working in my local copy is not worth making my source code incompatible with everyone else’s Inform builds imo.)
2 Likes
I implemented the Use flag; a PR is worth a shot. But what to call it that starts with “Use” and is reasonably clear and descriptive?
- Use no kind names as default plural dictionary entries
- Use no plural dictionary words by default
- Use manual understanding of plurals
- ?
1 Like
I’d go with either your third option (“Use manual…”), or perhaps “Use no automatic understanding of plurals”?
My vote is for “use no automatic plural synonyms” or “use no automatic plural understanding”.
1 Like
Use no automatic understanding of plurals for objects
1 Like