I7 - standard rules design philosophy
hari...@gmail.com
I came across this explanation for the blocked action "show
[something] to [someone]":
[--------------------------]
To make it into a systematic and interesting action, we would need to
unlist the block showing rule and then to write carry out and report
rules: but usually for IF purposes we only need to make a handful of
special cases of showing work properly, and for those we can simply
write Instead rules to handle them.
[--------------------------]
I've noticed before that the unofficial yet occasionally mentioned
phrase, "unlisting a rule" is not to be found in the documentation
(though if you read everything, you find the official term "removing a
rule from a rulebook" warrants a very brief mention at the bottom of a
page without mentioning the word "unlist" at all). Perhaps at the
very least, the manual page 18.4 can be retitled, "Listing and
unlisting rules explicitly."
However, I'm wondering the design philosophy behind why anything in
the standard rules would be set up as to REQUIRE unlisting rules to
make them work as expected. Unlisting or removing, it would seem to
me, as breaking the common design of how the standard rules work:
support a verb with the minimum and allow extensions easily. It feels
like unlisting would be an approach of last resort when doing
something particularly special or unexpected. In this case, why
wouldn't a simple standard rule be implemented to give the same "He
doesn't seem interested." output, while being much easier to expand by
games that wish to do so?
Andrew Plotkin
>
> However, I'm wondering the design philosophy behind why anything in
> the standard rules would be set up as to REQUIRE unlisting rules to
> make them work as expected. Unlisting or removing, it would seem to
> me, as breaking the common design of how the standard rules work:
> support a verb with the minimum and allow extensions easily. It feels
> like unlisting would be an approach of last resort when doing
> something particularly special or unexpected.
The design philosophy, as I see it, is: rules and rulebooks are the
main language constructs. The approach of *first* resort is to declare
a change to one of the standard rulebooks. Sometimes this means adding
rules, sometimes rearranging them, sometimes deleting rules, and
sometimes replacing one rule with another.
(The last resort is still replacing I6 routines!)
I agree that unlisting rules and extending rulebooks feel like
different design tactics, when they should be "the same thing" in some
sense. (Deleting a rule from the system should be a matter of
declaring "Instead of that: no-op"!) But this is not quite the way I7
works right now, and I can't offer you I8. :)
As it is, an unlisting declaration is short, efficient, and
incorporated into the programming feedback (the rulebook listings in
the Index tab). These things are on purpose.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
When Bush says "Stay the course," what he means is "I don't know what to
do next." He's been saying this for years now.