Is there any nitty-gritty documentation on how the compiler parses out a description (in the phrase sense)? It might help me understand what’s going on in something like the following:
[code]“The Tricky Part”
Test Chamber is a room.
A personality type is a kind of value. The personality types are alpha, beta and gamma. A person has a personality type.
A nose style is a kind of value. The nose styles are upturned, hawkish, and normal.
A nose is a kind of thing. A nose is part of every person. A nose has a nose style. A nose is usually normal.
Alice and Darya are women in Test Chamber. Alice’s nose is upturned. Darya is gamma.
Bob and Chris are men in Test Chamber. Chris is beta. Bob’s nose is hawkish.
Test me with “wave / jump / g / g / g / g / g / g”.
After waving hands:
repeat with examinee running through people:
say “[bold type][examinee][roman type]: [personality type of examinee], [nose style of a random nose part of examinee][line break]”;
say “[line break]”.
After jumping:
let LC be a random personality type;
let NS be a random nose style;
[ say “[LC], [NS]->[list of people that are LC incorporating a nose that is NS].”;] [doesn’t compile – what gives???]
say “[LC], [italic type]not[roman type] [NS]->[list of people that are LC incorporating a nose that is not NS].”[/code]
What’s the difference between the way the compiler sees the non-working line vs. the working line that makes it reject one but not the other? Is there some arrangement of parentheses I could use in the non-working line that would make it parse that line the right way (i.e. like the working line but without a negated condition)?
I don’t know. Multiple verb clauses in a description are tricky; it’s never clear what the compiler thinks is modifying what. I try to boil these down to single adjectives, as I did in the other thread.
Thank you for the direct and candid response, zarf.
I’m thinking I’ll file a bug report on this, based on the inconsistencies in what’s accepted as seen in:
After jumping:
let LC be a random personality type;
let NS be a random nose style;
say "alpha (hardcoded), upturned (hardcoded)->[list of people that are alpha incorporating a nose that is upturned]."; [basic syntax with hardcoded values OK]
[ say "[LC], [NS]->[list of people that are LC incorporating a nose that is NS]."; [... but this won't compile -- why?]]
say "[LC], normal (hardcoded)->[list of people that are LC incorporating a nose that is normal]."; [... but a hardcoded value in the same place is OK?]
say "[LC], [italic type]not[roman type] normal (hardcoded)->[list of people that are LC incorporating a nose that is not normal]."; [... and so is a negated harcoded value in the same place?]
say "[LC], [italic type]not[roman type] [NS]->[list of people that are LC incorporating a nose that is not NS]."; [... and so is a negated variable value in the same place???]
[ say "[italic type]not[roman type] [LC], [NS]->[list of people that are not LC incorporating a nose that is NS]."; [also won't compile]]
say "[italic type]not[roman type] [LC], [italic type]not[roman type] [NS]->[list of people that are not LC incorporating a nose that is not NS]." [... but negating both variable values does?]
From the above, I get the impression that I’m running into behavior that’s half-working (but is intended to be fully working). The use cases are similar enough that I don’t see any reason to allow some but not the others.
otistdog, did you ever file that bug report? If so, it will be looked at (obviously), and in the mean time it’s best to simplify things as zarf suggests as a working solution.
(I don’t really look at Mantis - I get all confused! So I only know if a bug’s been submitted if someone says it here. I appreciate this may duplicate work sometimes, but better a duplicate than silence, huh?)
Yes, I filed it as #1902 (inform7.com/mantis/view.php?id=1902). Thanks for following up, and for your ongoing maintenance of a “notable issues” digest for the forum here, which I’ve found to be very interesting reading.