Instead of taking the empty bowl


Im trying to write a line to stop taking the bowl when it is empty, but can’t work out how to do it. The last statement Instead of taking the empty bowl… doesn’t work and without the “empty” distinction , the bowl can not be taken at all .

Kitchen is a room. 
A counter is a supporter in the kitchen. 
A box of dogfood is an open container on the counter.  Understand  "box" or "dogfood" or "dog food" as the box of dogfood. 
A bowl is an open container on the counter. The bowl can be full or empty.
Dogbiscuits are edible things in the box of dogfood. 
Understand "dog biscuits"  or "dog biscuit" and "biscuits" as the dogbiscuits.

Instead of taking the empty bowl in the kitchen: 
say "put some dee...licious dog food in it first. "



The line “the bowl can be full or empty” define a property of the bowl that would have to be set using a line like “now the bowl is empty.” It’s no different from saying “the bowl can be spectacular or mundane” or something like that–Inform doesn’t know what “empty” is supposed to be mean unless you tell it!

One way to fix this is to make “empty” an adjective on containers that checks whether the container has anything in it, as discussed in section §11.16:

[code]Definition: a container is empty if it contains nothing.

Instead of taking the bowl in the kitchen when the bowl is empty:
say “Try putting some dee…licious dog biscuits in it first.”[/code]

(Now, why did I change it from “empty bowl” to “when the bowl is empty”? Because of a weird bug that seems to depend on the word “empty”! If you make the Definition “A container is unoccupied if it contains nothing” then you can say “Instead of taking the unoccupied bowl.” This is annoying but I’ll file a bug report about it.)

Another potential thing: The way this works, you can take the bowl even if the thing in it isn’t the dog biscuits. You might want this:

Instead of taking the bowl in the kitchen when the dogbiscuits are not in the bowl:

The bug is apparently caused by a clash with this line from the Standard Rules:

Definition: a table name is empty rather than non-empty if the number of filled rows in it is 0.

There is a similar bug with “full”, which is also defined as a table name adjective in SR.

“Empty” applies to various other kinds (rulebooks, activities, lists), but only the table name definition causes a problem.

It’s very weirdly specific, though. See the report here; it only applies when “empty” is used before the name of an individual thing rather than a kind name. In the Lemonade example from the documentation, which defines a kind “fluid container” and an adjective “empty” on it, you can say “Instead of giving an empty fluid container to Ted,” but if you try “Instead of giving the empty pitcher to Ted” it chokes.

I guess the syntax “the foo bar” as a short hand for “the bar […] when the bar is foo” is a special case, though. I’m not sure whether it’s documented anywhere? You can’t use adjectives to qualify names of things (as opposed to kinds) in other contexts. For instance, “try taking the foo bar” will never work (“too vague to describe a specific action”).

A special case presumably entails special code, which is presumably where the bug is. (But it’s presumably in the NI compiler, so we can’t look.)

It’s a supported feature as far as I know. I’ve certainly used it a bunch.

I don’t think “empty” is a special case in the compiler. You’re seeing a conflict between two definitions of “empty”. If you write a definition for table names being “unoccupied”, you run into the same problem.

Yes, it seems to be a conflict between a) adjectives defined for table names, and b) adjectives qualifying a named thing.

Edit: No, I’m wrong, it’s not just table names; it affects adjectives for lists, rulebooks, texts, activities too. (I’m not sure why I thought it didn’t.)

And here’s another case of the same bug.

The Market is a room. The bowl is a container in Market.
Definition: a container is empty if nothing is in it.

When play begins: 	
	let x be a random empty bowl;
	try taking x.

I suggest that this particular discussion head to the page for the bug report where it will be more likely to reach the people it needs to reach!

Very interesting. Thanks for the solution.


1 Like