Working fully around "is" in a thing name

The code below does not work in Inform 7, because Inform sees the first “is” in the “author” sentence and grabs it. This is perfectly reasonable compiler behavior.

a book is a kind of thing. a book has text called author.

There is a book called The Heart is a Lonely Hunter. author of The Heart is a Lonely Hunter is "Carson McCullers."

Now I can work around this with

author of Lonely Hunter is "Carson McCullers"

and I’m perfectly fine with that.

But it would be nice to be able to have the full name in the source, for general aesthetics, and also so I am sure namespaces don’t clash. (e.g. I could see myself getting lazy and calling it Heart, which might clash with Conrad’s Heart of Darkness. Or–and, yes, this would be bad design–if there were an ACTUAL lonely hunter in the game, things would get very sticky indeed.)

And I don’t want to make it privately-named, because then I’d need to do

hialh is a privately-named book. printed name of hialh is "The Heart is a Lonely Hunter".

understand "heart is a lonely hunter" and "lonely hunter" and "lonely/hunter" as hialh.

I’ve also tried things like putting the full book title in parentheses. Syntax like “if Hostile is He Lot is touchable” has no problems compiling and does what I’d expect. But with definitions outside of a rule, I can’t get the syntax to work.

Is there any way to allow for the full variable name easily? Saying "if hostile is he lot is

Actual not-so-simple full usage case enclosed, for the curious

For the one anagram game I wrote, there is an NPC called the Hostile-is-He Lot. I recently removed the hyphens to get rid of understand “hostile/is/he” code, which created compiling problems I worked around by calling it the He Lot elsewhere…

I wanted to be able to still easily test that the anagram clues were right, e.g. that the hinting device properly compared HOSTILE and IS HE LOT to HOLIEST. I have a python script that looks for and checks lines such as:

cheat-a-text of he lot is "RYRYYRR".
cheat-b-text of he lot is "??RYYR?".
[the question marks, if you're curious, are because the first letters of Hostile and Is He Lot alternately do and don't match up with the solution, Holiest.)

Then I calculate if the cheat-text is what it should be. (Writing this into a routine comparing clue-text and answer-text is possible, but 1) it’d require a huge rewrite and 2) Inform is a bit slow with regexes and text comparisons.) Having the full name in the source test is easiest. It seems there should be a way. (I suppose, if I really wanted to, I could write this in Inform 6 code.) But there is also not a bad workaround. My python scripts could define this stub:

def actual_name(x):
    return alternate_name[x] if x in alternate_name else x

alternate_name["he lot"] = "hostile is he lot"

But all the same, it’d be nifty if I didn’t have to.

I wanted to check if I was missing something.

This may be a bit of a nitpick, but I hope this is an interesting or useful general question brought up from my specific problem.

In general, no, I don’t believe there is any way to do that – you have to use a portion of the name or an alternative private name instead. (Private names have the advantage that you can completely control the understood fragments, rather than getting silly bindings like “is”.)

In terms of resolving ambiguity between this and an actual “lonely hunter”, the standard way to resolve that is either to use a private name for one of them, or to rely on Inform’s ambiguity resolution – within the compiler, a name will bind to an object in the closest section/chapter/part, so as long as you keep all references to the book separated from all references to the hunter, this will work.

Similarly, within the game itself, as long as those two objects are never in the same place at the same time then there will not be any visible ambiguity, unless you have some commands (like conversations) that allow discussing objects out of view. (One object being portable makes this more tricky to ensure, however; if you can’t avoid that then you might have to define some does the player mean rules.)

1 Like

Thanks. And yes, when writing this question, I completely forgot about “does the player mean doing something with Lonely Hunter: it is likely.”

It’s a life-saver in moderation, but I’ve had cases with namespace clashes forcing me into too many such rules, which leaves the door open for careless and difficult to fix bugs.

Yep. For assertions in the main source text, Inform will usually give you a compile failure when it thinks you’ve defined conflicting rules (two descriptions for the “same” object when you intended one to refer to the other one, for example).

Within rules, however, it can be harder to get compile failures, unless the two objects are of different kinds and you’re manipulating a property that can only exist on one of them. There, your best defense against unintended rebinding is to make use of the Skein and blessed transcripts, to alert you to unintended changes in behaviour elsewhere in your script. And trying to keep the rules relating to the objects close to the objects themselves, and in separate sections.

And test, test, test.

1 Like

My brutal solution is to link the words with hyphens:

the-heart-is-a-lonely-hunter

Understand “heart/hunter/lonely” or “is a lonely” as the-heart-is-a-lonely-hunter.

and then amend the printed name. It doesn’t matter that a player could theoretically type all that in: “x hunter” is a far more likely response.

That’s fine, but then you should also declare it privately-named, as shown in the original post. That avoids the possibility of weird parsing. :slightly_smiling_face:

1 Like

I disagree (as I always do). There is no possibility of weird parsing as long as the internal name is unique in the first 9 characters. People get way too wrapped up in using privately-named when it almost never matters.

That works, but it leads to bad habits. It’s a better habit to declare something as privately-named when you intend it to be so, even if it otherwise wouldn’t matter. Otherwise you’ll eventually be surprised when you happen to use a longer-than-9-character first word in your hyphenated phrase that does end up being ambiguous. (Also, IIRC the limit is smaller than 9 characters when using Unicode characters.)

Or if the player is just typing random things and happens to stumble across an internal object that you never intended for them to be able to manipulate. (Or at least not yet, for example if there’s an understand ... when rule applicable that they’re bypassing.)

2 Likes

Yeah, I’ve found that there’s a 1-in-50 chance something not privately-named will clash and create big headches later, and that’s too much. I’ve had times when I need to change something from being privately-named, but that’s okay. They’re found pretty quickly in testing, though.

I suppose it takes a second for me to make something privately-named, and if it eliminates a 1/50 chance of wasting over a minute later, it’s worth my time.

Having too much of this sort of detail work to remember would slow me down, but this is big enough I can check off on it.

[quote=“mirality, post:8, topic:45833”]Or if the player is just typing random things and happens to stumble across an internal object that you never intended for them to be able to manipulate
[/quote]

Yeah, silly related side story: this reminds me of how I put “blah” as a testing command outside a “not for release” block. And a tester got frustrated with the parser and typed “blah,” and it send them to a test-room where they could deal with all 24 enemies, instead of the 6 picked at random. This made them even more confused. Not confused enough to forget to UNDO, but confused enough.

At this point I created a not for release volume of programmer-testing/cheat commands.

2 Likes

Nope, still disagree. The bad habit is relying on privately-named in these situations.

Only in Z-code, which is no longer the default.

As I mentioned in another thread, stripping synonyms off an object is not a reliable way to guarantee this. If you want the player to not refer to an object, keep it off-stage.

(Maybe the library should have an “unreferrable” feature, distinct from privately-named. But currently it doesn’t.)

Which situations are you referring to? I can’t see how it’s a bad habit to use it for its sole intended purpose, of disabling the automatic Understand of every individual word in its story text name. I can’t think of any useful reason that “of” is an entirely sufficient synonym for “ball of twine”, for example.

Sure, most of the time it does no harm (and the player will get an ambiguity clarification if they attempt to use it inappropriately), but it’s still bad style to allow that sort of thing.

Similarly, even though the author may have chosen to use a hyphenated name or an abbreviation such as hialh for convenience in the source text, that doesn’t necessarily mean that it’s a name they want players to be able to use. Granted, the chances the player might stumble across such a name without prompting is small, but it’s still a question of style and correctness.

Or the name the author uses might contain spoilers, such as in the “secret document” example in the manual.

In general, yes. But that’s not always sufficient – the [any thing] token exists (and for example could be used in a conversation system to refer to off-stage items, as I said before).

And that’s not really what we’re talking about here anyway – we’re talking about things that should be on stage and interactable, just not with the name used in the story text.

2 Likes

That seems like a reasonable deal to me. I get headaches enough from my own coding goofs! And re: testing and not for release – duly noted, thanks for the tip!

1 Like