Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!solaris.cc.vt.edu!news.vt.edu!feed2.onemain.com!feed1.onemain.com!uunet!dca.uu.net!zur.uu.net!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Inform] Nice simple straightforward question
Message-ID: <GIDtso.844@world.std.com>
Date: Mon, 20 Aug 2001 19:50:48 GMT
References: <GIC6zC.B9M@world.std.com> <20010820095205.22541.00005372@mb-mj.aol.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 66
Xref: news.duke.edu rec.arts.int-fiction:91352

OKB -- not okblacke <brenbarn@aol.comRemove> wrote:
>buzzard@world.std.com  (Sean T Barrett) wrote:
>>The problem with the continuum of checks where order is not a
>>concern is that you either need two copies of your tests (one
>>which reports the error condition and one which prints the
>>error message), you need one copy with a global variable that
>>says whether to print or not (a la 'keep_silent'), or you need
>>the one place to be able to return both an error code and a
>>printable message. Since that printable message might want to
>>print things like the name of the object, it really needs to
>>return a little callable function which prints.
>
>     Basically, I agree that getting a system like this to work is going to
>take some doing, but your specific criticism seems to imply that we're using a
>sequence like Test->DoAction->TestAgain, whereas I'm thinking more like
>Test->DoAction->PrintMessage.  The key here is that the post-action bit does
>not re-test; its sole task is the printing of the message.  Now, we're
>definitely going to need some kind of storage for the results of the checks;
>it could be a bunch of globals, or it could be an array, or the stack.

I was describing three scenarios for implementing "storage for the
results of the check". The first two do it by using multiple calls,
because that's a realistic option to deal with the need for the
error messages to be functions-which-print-strings. You *could*
preprint all those strings (in *some* interpreters), but it would
be inefficient and you would quickly run into storage limitations,
since tens or twenties of messages could fire, and they could be of
arbitrary length. I don't think you can store the necessary info in
globals or on the stack, since there's an unknown series of them.

Thinking more carefully about this, I think focusing on the message
may actually miss the fact that overrides can and do sometimes have
side-effects; consider this scenario, taken from my unreleased
masterpiece, "Pick Up The Glass of Water and Die":

  > TAKE GLASS
  It's nailed down.

  > PUSH BUTTON
  A shimmering green wall of force flickers into existence around
  the pedestal (and the glass upon it).

  > TAKE GLASS
  Bob grabs your hand. "You idiot! Don't you know that force field
  is deadly?"

  > BOB, NORTH
  Bob departs to the north.

  > TAKE GLASS
  You reach for the glass... it happens so fast you can scarecely
  make out the details, but your hands seems to have entirely
  disappeared at the surface of the field. You try to pull your
  hand... well, your arm back, but it's stuck to the field, in
  fact it's disappearing further and further into it, sucked in
  by the field itself. The velocity at which your arm (and you) is
  sucked in increases, until you discover...

     *** You have died. ***

How do we defer the "deadflag=1" behavior, or some other side-effect
which the _override_ wants to have (this being the equivalent of a
react_before on the force field), if we don't call a function after
deciding which effect comes first?

SeanB
