I may have the terminology wrong. Are “grammar lines” just for the verbs (plus whatever tokens and prepositions) being mapped to actions as opposed to just “dictionary entries”?
I think so.
Thinking about it, the only situation in which ordinarily name/parse-name properties would be indistinguishable is when multiple indistinguishable objects have been created by ‘There are five animals in the Lab’ and such like. So this call to Identical() has been used as a shorthand to detect that scenario, without considering the possibility of multiple unnamed privately-named objects co-existing, which are also identical in that sense. Hence the assumption that all objects are of the same kind and it can just go with the kind of the first object in the list to describe them.
‘Dictionary entries’ are something else again- they are any word which has been indexed by the compiler for recognition by the parser, and may originate from name/parse_name properties or verb directives or prepositions in grammar lines or one or two other places.
… Okay, I retract my last response. After reading all the analysis, I’ve decided I do not know why I should not use ‘A thing is usually privately-named.’ 
Here’s how I would do it (assuming there weren’t any side-effects, and I’m saying if there are, I still don’t understand them in the abstract).
I would say 'a thing is usually privately-named.'
Then I would go through life creating things. Every single one of them is going to have an 'Understand 'bob' as wade-game-bob' type line, at least, giving each of them at least one specific name.
If I created plural objects that require a bit of finessing, like some cups, I would make them publicly-named, and/or of kind CUP if necessary, and then sort that finessing out.
So in these circumstances, what’s going to go wrong? I don’t think I care if someone actually types GET THINGS, because I’ve never typed that in my life. But I still want GET ALL to work, and I expect it would.
-Wade
Right. But if I want everything privately-named, none of these characters will be lacking an Understand as phrase containing both their name and probably at least 2-12 other words.
So the code will be like
Lab is a room.
A thing is usually privately-named.
Cerberus is an animal in the lab.
Understand "cerberus/dog" as cerberus.
Alice is a woman in the lab.
Understand "alice" as alice.
Bob is a man in the lab.
Understand "bob" as bob.
Which gives the desired output “You can see Cerberus, Alice and Bob here”.
Now if you say, why’d you want to add all those Understand lines?.. because in 95% of cases, I do want and need to add them. These characters here would be amongst the 5% of cases where I wouldn’t want to (because Bob’s name is really Bob, for instance) and in my new default setup of things being privately-named by default, they would be in the minority. But now in 100% of cases, I don’t have to say, or remember to say, ‘yada yada is privately-named’. That would be my goal.
So I’m trying to work out if there’s some glitch in this plan that I’ve I’ve overlooked or failed to understand during this topic. Or if what I’d like to do will work okay.
-Wade
I know I’m late, but is this the kind of interaction that you’re looking for?
You can see Alice, Beatrice and Cindy here.
>X ALICE
You see nothing special about Alice.
>X WOMAN
Who do you mean, Alice, Beatrice or Cindy?
>BEATRICE
You see nothing special about Beatrice.
>X WOMEN
Who do you mean, Alice, Beatrice or Cindy?
>ALICE
You see nothing special about Alice.
>X WOMEN
Who do you mean, Alice, Beatrice or Cindy?
>ALL
Sorry, you can only have one item here. Which exactly?
>CINDY
You see nothing special about Cindy.
>SAY HELLO TO WOMEN
You can't use multiple objects with that verb.
Yes, that’s right.
-Wade
So I tried an obvious naive solution to the “You can see three animals here.” problem with this modification to Identical in Parser.i6t:
[ Identical o1 o2 p1 p2 n1 n2 i j flag;
if (o1 == o2) rtrue; ! This should never happen, but to be on the safe side
if (o1 == 0 || o2 == 0) rfalse; ! Similarly
if (o1 ofclass K3_direction || o2 ofclass K3_direction) rfalse; ! Saves time
if (TEXT_TY_Compare(o1.short_name, o2.short_name)) rfalse; ! <-- modification
It seems to work… identical things are still grouped together without privately-named things of different kinds being grouped together. Is there a reason it’d be a bad idea?
Only in that comparing strings will be slower than comparing lists of dict word values. Comparing lists of dict word values isn’t speedy, there’s loops, but it’s generally faster than character-by-character string comparison.
This is a function that can be called a lot of times in generating a single room description.
The “correct” solution (in I6 days) is to write a parse_name routine that knows the object name behavior and can issue an identical/not-identical report very quickly. Unfortunately I7’s generated parse_name system isn’t set up to make that easy.
1 Like
I think there’s a potential issue.
I seem to recall this function is used not only by the listwriter but elsewhere by the parser’s disambiguation routines- to determine whether two or more objects are indistinguishable to anything typable in a command, which was I believe the original purpose of the function. As discussed above it is being hijacked by the listwriter for another purpose- one for which it was not designed and is not 100% suited.
The difficulty is that two objects may have differing short_names (for which you’re returning false) and yet be indistinguishable to the parser (which should return true).
2 Likes
ok, so we add a third parameter that ListWriter sets to true, and make the test:
if (lw && (o1 provides KD_Count) && (o2 provides KD_Count) &&
(o1.KD_Count ~= o2.KD_Count)) rfalse;
and we should accomplish:
- no effect on parser behavior
- not grouping together things of unlike base kinds during list writing
- plenty acceptable speed
Edited: actually, this can be just one line to the top of ListEqual in ListWriter; no need to touch parser code at all.
[ ListEqual o1 o2;
if (o1.KD_Count ~= o2.KD_Count) rfalse;
1 Like