A random thing with two conditions?

How can I do a condition like this?

let human be a random person that is not the dog that can be seen by the dog;

From what I can tell, Inform is interpreting this as “let human be a random person that is not (the dog that can be seen by the dog)” so it is selecting a random person that isn’t the dog. But I want a random person that the dog can see, but I don’t want to select the dog.

Another example

 let toy be a random dog toy which can be seen by the dog which cannot be touched by the dog;

Since the dog can touch itself, there is no toy ever that can be seen by the dog who can’t touch itself.

I usually do something like:

definition: a person is nondog is he is not the dog.

let human be a random nondog person who can be seen by the dog;

It’s kinda clunky, but when you write conditions with multiple clauses, it’s a crapshoot whether they’ll be interpreted correctly. The worst cases are the subtle ones, where the game seems to run fine but is doing some minor wrong thing that’s easy to miss…

You’ll stay saner if you avoid multiple clauses altogether.

I agree and it’s not a very impressive situation for a programming language, to be honest. Allowing parentheses would solve the whole shebang with usefulness to spare, but parentheses apparently aren’t elegant enough for a ‘natural language’ so therefore they are disqualified as a good solution, and so therefore there will be no good solution — or some similarly self-defeatingly form of theoretical fastidiousness. Programming language politics can attain comical heights of self-parody at times.

P.

Parentheses are allowed, although to be fair, I don’t think it’s documented anywhere except when used with equations. This works:[code]Lab is room. The dog is an animal in lab.
Sam, Joe, and Bob are men in the lab.
Al, Frank, and Tom are men.

Every turn:
let human be a random (person that is not the dog) that can be seen by the dog;
say “[human].”.

Test me with “z/z/z/z/z”.
[/code]
Edited to add: Having said that, I still generally go with a definition (as mucat suggested) since I know I’ll probably be using it more than once. It saves typing in the long run.

+1.

Jim, why are you +1ing this comment when it’s already been corrected?

I don’t know what you mean by “it’s already been corrected.”

I’m operating on the assumption that “+1” is shorthand for, “Me too – I agree.” If I’m under a misapprehension, I do hope someone will clear it up for me.

I expressed agreement because my overall impression of Inform 7 is that its programming syntax is a deeply entrenched mess. As I lurk on this forum, I often find myself rolling my eyes and making guttural noises when I see some of the confusion people stumble into, and some of the exotic syntax that is recommended for fixing the code.

I don’t often comment on same. In this case I thought I would do so, since someone else expressed sentiments similar to mine.

It means, Paul said that you can’t use parentheses to fix the OP’s problem, but you can, as skinnymike pointed out below his comment and above yours.

The Internet doesn’t always operate in what you and I would call real time. Mike’s message is stamped 5 hours before mine, but I don’t remember seeing it when I replied. Possibly I just missed it.

In any case, as Mike also pointed out, the use of parentheses seems to be undocumented. This fact, far from detracting from my general point, lends weight to it.

Well, that’s fine. Sorry for being slightly hostile about it.

I don’t think it does; I thought you were making a point about I7’s syntax, but the real problem here is with its documentation, which just about everyone agrees is at least flawed. (Though sometimes people seem to say it’s next to useless, and I don’t agree with that. After a little while with your handbook I started learning I7 by working through the documentation, and that has let me bootstrap my way up to a point where I can at least answer people’s questions sometimes.)

So a definition doesn’t really work for me, because I need it to be contextual. So I was trying to use a decide rule, like so:

To decide if a (foobar - thing) is out-of-reach of a (dog - canine): if the dog can see foobar: if the dog can touch foobar, no; yes; no.

But I can’t get the let statement to work:

let toy-alt be a random out-of-reach dog toy of the dog; let toy-alt be a random toy which is out-of-reach of the dog;

^ Neither of those work. (Part of the problem is the dog is a temporary variable holding the canine which is currently acting)
This approach seems like it would be most convenient but I am not sure how to make the let statement work correctly.

So this is a little baroque and probably supports Jim’s point about the syntax, but I think you might need to define a relation and an assertion verb, and use those in your let statement. Here you can define a relation that expresses a condition as in 13.12; you could actually build this on top of your definition, thus:

Frustration relates a thing (called X) to a dog (called Y) when X is out-of-reach of Y. The verb to frustrate (he frustrates, they frustrate, it is frustrated, he is frustrating) implies the frustration relation. ...Let toy-alt be a random dog toy that frustrates the dog;

I haven’t tested this, though, so the syntax might be off. Also I’m not sure why your second one doesn’t work – it isn’t because you have “toy” instead of “dog toy,” is it?

You might also be able to define frustration directly:

Frustration relates a thing (called X) to a dog (called Y) when Y can see X and Y cannot touch X.

Here’s another alternative (focusing on the fact that, as kanato pointed out, temporary variables aren’t quite as versatile as global variables. Also, karato, your attempted solutions were kind of blurring the distinction between phrases and definitions, which are not the same thing…)

globaldog is a dog that varies.
definition: a toy (called t) is tantalizing if globaldog can see t and globaldog cannot touch t.

...

now globaldog is rover;
let t be a random tantalizing toy;