properties with boolean logic, and indefinite articles


I have the following code, and I’m not sure why it doesn’t work:


A cloak is a wearable thing. The description of the cloak is “[The player] USE this cloak to sneak around at night undetected.” The cloak is on Levalia’s bed.
[the bed is an enterable scenery supporter that has nothing to do with this particular piece of code]

A person can be visible or invisible.
last carry out using the cloak:
now the player is invisible.
[using is a new action I created; that can be disregarded as well]

Book - some scratch testing

A guard is a kind of targetable person. Understand “guard” as a guard. The printed name of a guard is usually “GUARD”. A guard is privately-named. The indefinite article of a guard is “a”.
[targetable is also a new property, as created by this extension called Basic Combat by B David Paulsen]

G1 is a guard in Wkitch.

Check going to EKitch:
if the guard is not dead and the player is visible:
say “[The g1] stands in your way.”;
the rule fails;
continue the action.[/code]

The issue I have is that even if I’m wearing the cloak (making me invisible), the guard still stands in my way. If I replace “the player is visible” with “the player is not wearing the cloak”, it works fine. I just would like to understand why using visible/invisible properties won’t work.

The second issue I have is one that I’ve had for a long time, and I think it’s time I finally get it tackled. When printing the paragraph about the guard, the parser says “You can see GUARD here”. Obviously, I want it to say “You can see a GUARD here.” (there’s no issue if there’s two guards in the room). I’m 100% sure I have some misconception about how to properly use “The indefinite article of… is…”, or if it’s even appropriate in this regard.


I believe this is because “visible” already means something different to Inform (see §6.13 in the documentation). It works if you use “cloaked or uncloaked” instead of “visible or invisible”.

(It would be nice if Inform threw an error at your redefinition of “invisible”, but apparently it doesn’t. Standard Rules defines it as a definition, whereas you define it as a property, so it’s not technically conflicting - it’s just confusing since you can check a definition or a property using the same syntax.)

This is tricky behavior. The property you’re looking for is “improper-named”, but you can’t do the obvious and just say A guard is improper-named. because Inform is overriding this at the object level, when you define G1. The definition of G1 has no article (“G1 is a guard…”), so Inform assumes you mean it to be proper-named.

You could do: The G1 is a guard in Wkitch. Or: G1 is a guard in Wkitch. It is improper-named. Or: A guard is always improper-named. …which is a useful bit of syntax for dealing with kinds (see §4.3 in the documentation).


Oh man, I’m such an idiot. I didn’t even think of the fact that “visible” already exists. Thanks, prevtenet! That was a nice, easy fix.

I seem to be needing some further understanding with proper-named vs improper-named, singular and plural, etc. In actual English grammar, I understand what all those things mean, but they seem to mean something slightly different in Inform… or at least, I get different results than what I expect when trying to use them. When I say something is proper-named, I’d expect it to merely capitalize the noun (as if it was a proper noun). The documentation (3.18) gives a little clarity on singular-named vs plural-named, but I still can’t seem to be able to apply it properly in my actual programming.


The proper-/improper-named property has no effect on capitalization. It just determines whether an article is printed before the object’s name.

The singular-/plural-named property determines what the indefinite article is — a(n) or some — unless this has been set manually. It also ensures the correct conjugation of verbs, such as is/are. (Also, it affects what pronouns the player can use to refer to the object.)

Inform makes various decisions for itself about objects when they are first defined in your code — about capitalization, improper-/proper-named, singular-/plural-named, and the indefinite article. It assumes that your usage there expresses your intentions. Usually you can get the effect you want by phrasing the initial definition of the object correctly; but you can always override Inform’s guesses, and sometimes you have to.

Great Expectations is a thing.

This creates a proper-named thing with a capitalized name.

There is a thing called literature.                      [or just "literature is a thing."]

Creates a proper-named but uncapitalized thing.

The Victorian novel is a thing.

This creates an improper-named thing. The indefinite article is not changed from the default “” (which prints as “a” or “an” as appropriate). The word “Victorian” in the name is capitalized.

There is a thing called the Victorian novel.

Similar to the above, but this more emphatic form of the definition persuades Inform to set the indefinite article to “the”.

Some books are a thing.          [or "is a thing" or "are things"]

The word “some” causes Inform to make this plural-named. The indefinite article isn’t changed from the default “”, but this prints as “some” for plural-named objects.

(Inform won’t act on hints any more delicate than these. “Some semolina is a thing;” creates a plural-named thing, and not — as you might hope — a singular-named thing with indefinite article “some”. And “There are things called the cardinal virtues;” creates a singular-, not a plural-named thing.)

(Hanon Ondricek) #5

One other side note - when you’re using a token substitution to call the name of an object, Inform looks whether you’ve included an article in the token and thusly will use it or not.

say “Boris draws his [weapon] and swings it mightily” - should produce “Boris draws his sword and swings it mightily.”
say "You pick up [the weapon] and stash it in your inventory - should produce “You pick up the sword and stash it in your inventory.”
say “You select [a weapon] for use later” - “You pick up a halberd for use later”

(providing, of course, Inform knows what weapon you’re talking about; you can also say [noun] [the noun] [a noun] etc…to use the object in the player’s command)

Inform will observe whether something is proper or not and should say the article appropriately so long as you’ve defined the object properly as jrb details above.

“You pick up [the captive].” should appropriately say “You pick up Rumplestiltskin” vs “You pick up the gnome.”

You can also capitalize as appropriate.

“[The captive] glares at you” - “The gnome glares at you.” “Rumplestiltskin glares at you.”


Okay, so if I wrote something like

Keys are a thing. [creating a proper-named thing... then wrote:]  Keys is improper-named.

The last line, “Keys is improper-named” will override the original setting I created and print singular articles (a, the) before it. If I say that Keys is plural-named, then it would print “some” before it instead.

Regarding tokens, I kind of already knew that if I include “a” or “the” in the token, it would print the article along with the noun, but I had originally thought it would just print the article no matter, since I included it. As I understand it now, if I created something like:

[code]Excalibur is a weapon. [proper-named]
A club is a weapon. [improper-named]

Carry out taking a weapon:
say "You pick up [the weapon] and stash it in your inventory[/code]

Then, even though there is “the” in the token, if I pick up Excalibur, it will say “You pick up Excalibur…”, but if I pick up the mace, it will say “You pick up the mace…” Alternatively, if I had written “You pick up [weapon]…”, then Excalibur would print fine, but the mace would print “You pick up mace…”

Is that right?

One last thing… How does “The indefinite article of…” work?

I take it back. One other last thing… If you’ll notice, I made the guards a privately-named thing. This was imitated from something else I saw in the recipe book somewhere, and I’m not really sure what it means. I looked in the documentation and found a bit of explanation under 17.17, but it says that if something is privately-named, the player can never refer to it. So why then, can the player refer to the guard? Or rather, does it mean the player would never be able to refer to the guards as G1, G2, etc?

(Andrew Plotkin) #7

No. It just means that the source-code name is not added to the synonym list.

If you don’t know what privately-named means, stop using it. If you use it by habit or because you copied an example, stop using it. If you can’t point to a specific bug in your game which is fixed by privately-named, stop using it.

(Daniel Stelzer) #8

Exactly. Privately-named isn’t a real property, in that you can’t use it during play. It just tells the Inform compiler that the name used in the source code shouldn’t be understood by the parser.


Thanks, Draconis. Sorry for my incompetence, Zarf. I tend to use things I don’t understand because it helps me accomplish what I’m trying to accomplish, as well as starts to give me more understanding of how something works or, at the very least, makes me curious about it. If I don’t use something I don’t understand, I’ll never learn about it and consequently never improve.

(Andrew Plotkin) #10

I am not ragging on you in particular. I am trying to increase the chance that people in the future see and remember this advice.


Well, you can if you really want to.

The foo is a privately-named thing. The bar is a thing.
When play begins:
     say the list of privately-named things.

Prints “yourself and the foo”.

One reason not to use privately-named extensively is that you’ll quickly run up against bugs; apparently it’s not too robustly implemented. I’ve found two in just a few minutes of playing around with it.

Number one:

X is a room. The foo is a privately-named thing. The bar and the qux are things.
When play begins:
	say "[the list of privately-named things].";
	now the foo is not privately-named;
	say "[the list of privately-named things]."


(This is weird. Probably the code shouldn’t compile anyway, because it doesn’t mean anything to toggle privately-named at runtime.)

And number two:

X is a room. The foo and the bar are privately-named things in X.

(Not serious, because you wouldn’t use privately-named without setting a printed name, or otherwise dealing with how they appear in room descriptions. But it contrasts oddly with the case where only one privately-named object is declared:

(matt w) #12

To be clear, the context is this:

which is saying that if you declare something privately-named and don’t include any other “Understand” lines for it then the player won’t be able to refer to it. In your code, the player could refer to the guards because you had another “Understand” line that let them use “guard” to refer to guards.

(Daniel Stelzer) #13

I’d file that as a bug. Privately-named shouldn’t affect how it displays, according to the manual. It only affects the parser.

(matt w) #14

I’d guess the thing that’s going on there is that, when two things have the same dictionary entries, Inform tries to lump them together as generic objects of their kind. Usually this happens with a kind creation like “A rock is a kind of thing. Two rocks are in the Quarry.” The foo and bar have the same dictionary entries because they have no dictionary entries at all, but it prints a blank instead of “things.”

In fact you can create the same effect with this:

Lab is a room. Two things are in the Lab.

You get “You can see two here” because Inform doesn’t distinguish the two things, and doesn’t have anything to call them.


Yes, you’re right. It’s not really a bug with privately-named at all.

Actually, I don’t think it counts as a bug. If the author doesn’t give Inform any vocabulary to work with, what’s it supposed to do? (The thing that upsets me a little about it is the double space between “two” and “here”; but that probably says something about me.)

(I stand by my number one bug, though. Trying to toggle privately-named off for one object shouldn’t toggle it on for everyting else!)

(Daniel Stelzer) #16

I’d still call it a bug tbh. “There are two people in the lab” is valid, why not “two things”? But it does make more sense where it’s coming from now.

(Hanon Ondricek) #17

This example is kind of useless, but likely applies more complicatedly to other things:

[code]Lab is a room.

some trousers are here. They are wearable. The indefinite article of trousers is “a pair of”. Understand “pair” and “pair of” as trousers.

Some underpants are here. They are wearable.

A wearable thing called The Amulet of Moloc is here. It is proper-named.

The indefinite article of underpants is “[if underpants is worn by the player]your[otherwise]some[end if]”.

Understand “my underpants” and “your underpants” as underpants.

Report taking inventory:
if the player wears something:
say “You look spiffy in [a list of things worn by the player].”[/code]