|Anonymous | Login | Signup for a new account||2018-12-18 07:12 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001040||Core Inform||Assertions and creations||public||2012-10-24 12:07||2014-05-07 07:33|
|Target Version||Fixed in Version||6L02|
|Summary||0001040: "X is always in R" does not work the same as "all X are in R"|
|Description||In the sample below, I'm trying to put all X (a kind of room) in a particular region.|
My first try was "An X is always in R," which didn't work. Okay, I figured, this must not be possible. But then I tried the alternate form "All X are in R," which *did* work.
The same distinction arises when X is a kind of thing, and R is a specific room. ("All X are in the Kitchen" vs "An X is always in the Kitchen.")
The difference is not obvious to me as a user (even as an experienced user). I can understand if you don't want to accept "...is usually...", with exceptions, but a universal declaration should work.
|Minimal Source Text To Reproduce|
"Test Case" by Andrew Plotkin. R is a region. An X is a kind of room. [All X are in R.] An X is always in R. The Kitchen is an X. ! Problem: You wrote 'An X is always in R' : but something described only by its kind should not be given a specific place or role in the world, to avoid ambiguity.
|Tags||No tags attached.|
|Effect||(cosmetic) Error message is badly worded|
|Can't you only use "always" for properties rather than relations? "All X are in Y" makes sense as it's making an initial compile time declaration, but how would the compiler implement "An X is always in the Kitchen"? Add in extra check rules to stop it moving?|
I'm saying that the compiler should treat these declarations the same.
"The prop of an X is always Y" *is* a compile-time declaration. Nothing in the system prevents you from changing the property at runtime.
(I wouldn't mind if the compiler accepted the analogous declaration for properties: "The prop of all X is Y." Currently it doesn't.)
I realize that this is a subcase of the general declaration "<description> is <whatever>", and this is *in general* not supportable at compile time. I don't expect the system to handle "Some X are in R" or "All lit X are in R" as compile-time declarations. But "all X" seems like it's worth treating specially.
It's true that "always" currently only affects compile time declarations, but the documentation at WI 4.3 ("Degrees of certainty") and the commentary on example 43 ("Something Narsty") suggest that it was intended to apply at runtime too:
Inform would not have permitted any exception to be made, and would have reported a problem if we had tried to make the ["always dark"] Tortuous Alcove lighted.
Defining the staircase this way ["A staircase is always open"] means that we will never be able to get away with (for instance) a folding ladder into the attic which is sometimes closed up.
So I'd say that being able to change such properties at runtime is actually a bug. (Note the use of "sometimes closed up" rather than "initially closed up".)
In any case, the problem message could be improved by referring to the syntax that works.
|Assertions like "An X is always in R." are now read as equivalent to "All X are in R".|
|2012-10-24 12:07||zarf||New Issue|
|2012-10-24 23:02||curiousdannii||Note Added: 0001917|
|2012-10-24 23:27||zarf||Note Added: 0001918|
|2012-10-24 23:32||zarf||Note Added: 0001919|
|2013-03-30 04:28||jmcgrew||Effect||(serious) Compiler rejects valid code => (cosmetic) Error message is badly worded|
|2013-03-30 04:28||jmcgrew||Note Added: 0002001|
|2013-03-30 04:28||jmcgrew||Severity||mild => cosmetic|
|2013-03-30 04:28||jmcgrew||Status||new => confirmed|
|2014-01-25 03:20||graham||Note Added: 0002351|
|2014-01-25 03:20||graham||Status||confirmed => resolved|
|2014-01-25 03:20||graham||Resolution||open => fixed|
|2014-01-25 03:20||graham||Assigned To||=> graham|
|2014-05-07 07:32||jmcgrew||Fixed in Version||=> 6L02|
|2014-05-07 07:33||jmcgrew||Status||resolved => closed|
|Copyright © 2000 - 2010 MantisBT Group|