Any "condition"-like shorthand for an either-or property?

WWI 4.10 Conditions of things discusses how properties with at least three states will be assigned a name that serves as a text substitution, e.g. “[cask condition]” or “[squishiness]”.

Is there anything like that for either-or properties? I’m hoping to be able to say

`The description of the generic device is "On inspection, you can see that it is [switched on property]."

instead of

`The description of the generic device is "On inspection, you can see that it is switched [if switched on]on[otherwise]off[end if]."

If the feature doesn’t exist, does anyone else think it’s worth a feature request?


It sounds reasonable, but how would you name it? Either/or conditions are determinedly anonymous. If you follow the pattern of “cask condition” then scenery would be, like, “thing condition 4”, which is pretty bad.

Maybe “either/or condition lit” or just “the lit condition”. (With the understanding that “the unlit condition” would refer to the same thing – no need to remember which is positive.) But the former is wordy and the latter might crash into other syntax.

I was thinking [switched on condition], which is like your [lit condition] example.

The compiler can already handle cask vs. [cask] vs [cask condition], which don’t (naively) seem that different.

1 Like

Yeah, but lit or switched on by itself is a valid description, as well as an adjective. This already causes a fair amount of confusion.

Ah. I get it.

Maybe handle it similarly to properties (the X property or the property X)?

1 Like

The generated I6 “knows” the names of the positive forms of the either-or properties, but not the negatives (outside of showme, where they’re hard-coded). So among the necessary changes would be maintaining the name (if there is one) for the negative.

4.10 falls short of saying a condition has to be of at least 3 states. And if you try to compile something with

A thing can be larry or moe (this is its stooge property).

you’ll get

A thing can be larry or moe (this is its stooge property)’ (line 7): but a name can only be supplied using ‘… (this is…)’ when a new property is being made with three or more named alternatives, whereas here a simpler either/or property is being made with just one or two possibilities - which means these named outcomes are the property names themselves. For instance, ‘A book can be mint or foxed’ makes two either/or properties, one called ‘mint’, the other called ‘foxed’. So ‘A book can be mint or foxed (this is the cover state)’ is not allowed.

However, this works:

lab is a room.

hardness is a kind of value. Hardnesses are squishy, unyielding.
a thing has a hardness.
the plushie is in the lab.
the rebar is in the lab. it is unyielding.

the description of a thing is usually "[They] [are] [hardness]."

test me with "x plushie / showme plushie / x rebar / showme rebar".


You can see a plushie and a rebar here.
>test me
>[1] x plushie
It is squishy.
>[2] showme plushie
plushie - thing
location: in lab
unlit, inedible, portable; singular-named, improper-named
description: "It is squishy."
initial appearance: none
hardness: squishy
printed name: "plushie"
printed plural name: none
indefinite article: none
list grouping key: none
>[3] x rebar
It is unyielding.
>[4] showme rebar
rebar - thing
location: in lab
unlit, inedible, portable; singular-named, improper-named
description: "It is unyielding."
initial appearance: none
hardness: unyielding
printed name: "rebar"
printed plural name: none
indefinite article: none
list grouping key: none

Doesn’t help you with the built-in either-ors, of course. And there’s an efficiency advantage to either-ors implemented as I6 attributes that you’d never get with a condition of two like this.

Is it too much of a nuisance to work around it for the either-or properties you need by making “to say” phrases?

To say (machine - a device) status:
	if machine is switched on, say "ready and waiting";
	otherwise say "dormant and unresponsive";

The other deficiency is that Inform can’t recognize that “not squishy” necessarily means “unyielding”.

1 Like

Right. One could, I suppose, do:

to decide what hardness is not squishy: decide on unyielding.
to decide what hardness is not unyielding: decide on squishy.


a hardness variable called not squishy is always unyielding.
a hardness variable called not unyielding is always squishy.

but it feels like asking for trouble.

Is that really the case if there are only two possible values?

Try it.

Well, it’s a nuisance, but at least it’s a finite nuisance…

To decide which number is (P - either-or property) self-value:
	(- (GetEitherOrProperty(self, {P})) -).

To say (P - either-or property) condition:
	let V be P self-value;
	if P is:
		-- switched on:
			if V is 1, say "switched on";
			otherwise say "switched off";
		-- lit:
			if V is 1, say "lit";
			otherwise say "unlit";
1 Like

I had, actually. Using Zed’s example scenario plus:

When play begins:
	showme the list of not squishy things;
	showme the list of not unyielding things.

I get:

"list of not squishy things" = list of things: {rebar}
"list of not unyielding things" = list of things: {yourself, plushie}

EDIT: Were you talking specifically about assignment? That (sensibly) doesn’t work.

Problem. You wrote ‘now yourself is not unyielding’ : but this is not something I can make true with ‘now’, because it is too vague about the underlying cause which would need to be arranged.

Yep, I was talking about assignment. I hadn’t thought about the “list of not squishy things” case, which works. As does “if X is not squishy”.

Maybe the best way forward here is to close the assignment hole. That is, make the compiler smart enough to accept “now X is not V1” when the KOV has just two values (V1, V2). I think that would then be completely substitutable for an either/or condition, which solves this whole problem.

Well, my original goal was to find a say statement for the value held in the either-or property, not to make assignments of values, and in particular for the core either-or properties specified in the Standard Rules. Would all of those be rephrased as enumerated values?

As far as naming goes, even something as verbose as “[open property condition]” would seem like a net win to me vs. having to type out the [if...]...[otherwise]...[end if] pattern every time it comes up. Using “[open condition]”, “[lighted condition]”, etc. would be ideal in my mind, though recognizing the bit-negative value’s name as you suggest would probably be handy.

Looking at the generated I6 code, my workaround is looking pretty fragile:

[ PHR_806_r46  
	t_0 ! Call parameter 'P': either/or property
	tmp_0 ! Let/loop value, e.g., 'V': number

	! [2: let v be p self-value]
	tmp_0 = (GetEitherOrProperty(self, t_0));

	! [3: if p is]
	switch (t_0) 
	{ambigpluralname:		! <--- raw attribute identifier!
	    ! [4: if v is 1]
	    if (((tmp_0 == 1)))
	    {! [5: say ~ambiguously plural~]
	        say__p=1;! [6: ~ambiguously plural~]
	        ParaContent(); print "ambiguously plural"; .L_Say467; .L_SayX465;} else {
	        ! [7: say ~not ambiguously plural~]
	        say__p=1;! [8: ~not ambiguously plural~]
	        ParaContent(); print "not ambiguously plural"; .L_Say468; .L_SayX466;}

In fact, using the bit-negative value of the pair as the I7 “switch” value causes an I6 compiler failure, because the attribute identifier is preceded by a tilde. It seems to be working more by happenstance than by design, and only because I6 is happy to treat the attribute ID as a number.

Would it help to use a syntax that requires specifying both the positive and negative adjective? Something like [whether] open or closed [condition].

For 9.3/6M62:

to say (p - property) for (o - object): (- 
if ({o} hasnt {p}) print "not "; 
print (string) property_metadata-->(attributed_property_offsets-->{p});

basket is an openable closed container.

when play begins:
say openable for basket;
say ".";
say open for basket;

You would need to populate a lookup table with the opposite names, like “closed”, basically.

Delving back into the vault of failed experiments (this is for 9.3/6M62). The tl; dr is that the code below sets up the lookup table I referred to above such that one can get closed instead of not open. It’s not a very ergonomic API; this is just a proof of concept. This also omits a bunch of run-time error-checking that I7’s attribute-handling normally has. (It’s not called “safety-first science.”)

lab is a room.

Table of mad props
propcol (property)      oppcol (text)
with 50 blank rows.

A thing can be animate.
the animate property translates into I6 as "animate".
A thing can be talkable.
the talkable property translates into I6 as "talkable".
a thing can be worn.
the worn property translates into I6 as "worn".

first when play begins:
[ absent, container, door, supporter, removeproper, mark_as_room, mark_as_thing, workflag, workflag2 ]
[the opposite of privately-named is "publicly-named";]
[add unproperty mentioned;]
[add unproperty marked for listing;]
add unproperty lit;
add property wearable;
the opposite of edible is "inedible";
the opposite of fixed in place is "portable";
add property scenery;
add property pushable between rooms;
the opposite of undescribed is "described";
add property handled;
the opposite of switched on is "switched off";
the opposite of female is "male";
add property neuter;
add property lockable;
add unproperty locked;
opposite of open is "closed";
add unproperty openable;
add property enterable;
opposite of transparent is "opaque";
add unproperty visited;
add property ambiguously plural;
opposite of proper-named is "improper-named";
opposite of plural-named is "singular-named";
add property animate;
add property talkable;
add property worn;

to say (p - property) for (o - object): (-
if ({o} hasnt {p}) print "not ";
print (string) property_metadata-->(attributed_property_offsets-->{p});

to decide if (o - object) i6provides (p - property): (- WhetherProvides({o}, 1, {p}) -)

to say (p - property) vs (t - text) for (o - object): (-
  if ({o} has {p}) print (string) property_metadata-->(attributed_property_offsets-->{p});
  else TEXT_TY_Say({t});

to say (p - property): (- print (string) property_metadata-->(attributed_property_offsets-->{p}); -)

to say attdump (o - object):
  repeat through table of mad props begin;
    if o i6provides propcol entry, say "[propcol entry vs oppcol entry for o].";
  end repeat;

to add property (p - property):
  opposite of p is substituted form of "not [p]".

to add unproperty (p - property):
  opposite of p is substituted form of "un[p]".

to opposite of (p - property) is (t - text):
choose a blank row from table of mad props;
now propcol entry is p;
now oppcol entry is t.

when play begins:
say "Yourself: [line break][attdump yourself]";
say ".";
say "Lab: [line break][attdump lab]";


not wearable.
not scenery.
not pushable between rooms.
not handled.
not neuter.
not ambiguously plural.
not talkable.
not worn.
not ambiguously plural.

There’s a tricky thing going unmentioned: “lighted” and “lit” name the same property. You can use any of “lighted”, “lit”, “not lighted”, “not lit” with either rooms or things. But you can use “unlighted”, “not unlighted” only with rooms and “unlit”, “not unlit” only with things, or I7 will give you a compiler error.

An unrelated lesson learned – these are all very different things and can and will produce different results for the same o, p.

  • o provides p in I6
  • WhetherProvides(o, 1, p) in I6
  • o provides p in I7
1 Like

That’s a bit of a straw man. If it came up frequently in a game, you’d write a shortcut say phrase, as Josh Grams suggested somewhere up there. If I7 generated that phrase automatically, it would only save a small amount of effort.

Straw man? The only reason the idea even occurred to me is because it comes up just frequently enough to be bothersome. When I thought about why it was bothersome I realized that it’s because there’s an inconsistency in the affordances offered to the author. For three-value-plus properties, the text substitution is automatically generated, but for two-value properties, it’s not. Is there a good reason for this discrepancy beyond “it’s just the way the feature set has evolved?”