How far do you go? (longish)

15 views
Skip to first unread message

Sami

unread,
Jul 3, 2007, 5:37:34 PM7/3/07
to
I am just about ready with version 2 of Labyrinth. I had intended to
have this ready several months ago, but my job got crazy, then I
acquired a new time-sucking hobby, and last but not least I7 took me
longer to figure out than I thought it would. ANYway, the new version
is almost ready - I'm working on making one of the NPC's a little more
interactive, and then I'll be looking for beta-testers. (Should be a
week or two, so feel free to let me know now if you're interested.)

However, there were some things that I was still not able to get
working exactly the way I wanted, and I was wondering how far most of
you will go in anticipating difficult-to-implement player commands
before you decide that it's just not worth it.

Since there's a game of Nim inside my game, the main problem I'm
having is with numbers. At the start of the Nim game, the player is
told to type "take <number>" - how far should I go to implement
responses to commands that are not of that form? I especially hate
the response when the player spells the number out:

>TAKE TWO
nim counter: Please use the form "take <number>."
nim counter: Please use the form "take <number>."

I also have a decent response when the player types TAKE <number>,
where the number is not within the allowable range. However, this
fails when that number is assigned by Inform to one of the objects:

>TAKE 7
You must take 1 to 5 counters.

(OK.)

>TAKE 63
Don't be rude! Leave the box alone until you're finished playing.

(Uh, what? Plus, the box is not even in the current location!)

I don't think there's anything I can do about these problems. How
much do you feel you are responsible for giving a player good
responses when he is obviously not following your directions?

My other main problem is with the "you must name something more
substantial" response when the noun is a direction. If the location
is indoors, the direction represents a wall, which *is* substantial.
For certain actions necessary for winning the game, I used a
workaround of "Understand 'blah' as something new" and defining a new
action which applies to visible instead of touchable things. But
seriously, do I have to do that for every single action? Is it worth
it? Should I just let it go, and then do it just for the actions that
my beta-testers try?

>HIT NORTH WALL
You must name something more substantial.

Argh.

Emily Short

unread,
Jul 3, 2007, 6:01:24 PM7/3/07
to
On Jul 3, 2:37 pm, Sami <hbaf...@yahoo.com> wrote:
> However, there were some things that I was still not able to get
> working exactly the way I wanted, and I was wondering how far most of
> you will go in anticipating difficult-to-implement player commands
> before you decide that it's just not worth it.

I'd fix all of these, yes. That doesn't mean you can't get some help
with them, though!

> Since there's a game of Nim inside my game, the main problem I'm
> having is with numbers. At the start of the Nim game, the player is
> told to type "take <number>" - how far should I go to implement
> responses to commands that are not of that form? I especially hate
> the response when the player spells the number out:
>
> >TAKE TWO
>
> nim counter: Please use the form "take <number>."
> nim counter: Please use the form "take <number>."

You could substitute these out, I suppose:

<code>
After reading a command:
repeat through the Table of Numerical Substitution
begin;
if the player's command includes topic entry, replace the matched
text with the replacement entry;
end repeat.

Table of Numerical Substitution
topic replacement
"one" "1"
"two" "2"
"three" "3"
"four" "4"
"five" "5"
"six" "6"
"seven" "7"
"eight" "8"
"nine" "9"
"ten" "10"
</code>

> >TAKE 63
>
> Don't be rude! Leave the box alone until you're finished playing.
>
> (Uh, what? Plus, the box is not even in the current location!)

That's pretty mysterious -- possibly even a bug in Inform -- but I'd
need sample source code to diagnose it further.

> My other main problem is with the "you must name something more
> substantial" response when the noun is a direction. If the location
> is indoors, the direction represents a wall, which *is* substantial.
> For certain actions necessary for winning the game, I used a
> workaround of "Understand 'blah' as something new" and defining a new
> action which applies to visible instead of touchable things.

I wouldn't do that, partly because it's tedious and repetitive coding
but mostly because the touchability restriction is important to making
sure the action works only in sensible cases.

I'd suggest, instead, that you make a wall or multiple wall objects
that are *not* identical with the direction objects; these will then
be treated, sensibly, as physical constructs, and can be placed in all
your indoor rooms at need. Depending on exactly what you're doing,
this may raise some challenges disambiguating between the wall and the
compass direction, but I'm pretty sure this will be easier to resolve
than the existing problem, and produce more consistent results.

Sami

unread,
Jul 3, 2007, 7:20:41 PM7/3/07
to
On Jul 3, 6:01 pm, Emily Short <emsh...@mindspring.com> wrote:
> You could substitute these out, I suppose:
>
> <code>
> After reading a command:
> repeat through the Table of Numerical Substitution
> begin;
> if the player's command includes topic entry, replace the matched
> text with the replacement entry;
> end repeat.
>
> Table of Numerical Substitution
> topic replacement
> "one" "1"
> "two" "2"
> "three" "3"
> "four" "4"
> "five" "5"
> "six" "6"
> "seven" "7"
> "eight" "8"
> "nine" "9"
> "ten" "10"
> </code>

Ah, I didn't think of using a table for that. I tried:
Understand "one" as 1. Understand "two" as 2. etc.
which gave me that weird error message about compiling but still not
translating successfully into a game.

I also tried a few other things, none of which worked.

> > >TAKE 63
>
> > Don't be rude! Leave the box alone until you're finished playing.
>
> > (Uh, what? Plus, the box is not even in the current location!)
>
> That's pretty mysterious -- possibly even a bug in Inform -- but I'd
> need sample source code to diagnose it further.

I don't think it's a bug - I noticed when learning I6 that objects had
numbers assigned to them. Normally, no player would ever notice such
a thing, but it comes up when you have numbers that are acceptable
nouns. For whatever reason, the parser will first choose the assigned
object rather than the actual number. My code is just:

<code>
Playing nim is an action applying to one number. Understand
"[number]" and "take [number]" and "take [number] counter" and "take
[number] nim counter" and "take [number] counters" and "take [number]
nim counters" as playing nim.

Carry out playing nim:
if the number understood is less than 1, say "[wrong number response]"
instead;
if the number understood is greater than 5, say "[wrong number
response]" instead;
[snip rest of rule as not applicable here]

To say wrong number response: say "You must take 1 to 5 counters."
</code>


> I wouldn't do that, partly because it's tedious and repetitive coding
> but mostly because the touchability restriction is important to making
> sure the action works only in sensible cases.
>
> I'd suggest, instead, that you make a wall or multiple wall objects
> that are *not* identical with the direction objects; these will then
> be treated, sensibly, as physical constructs, and can be placed in all
> your indoor rooms at need. Depending on exactly what you're doing,
> this may raise some challenges disambiguating between the wall and the
> compass direction, but I'm pretty sure this will be easier to resolve
> than the existing problem, and produce more consistent results.

That's an idea. I already have some wall objects (which correspond to
colors rather than directions), but I suppose I can make some more.

Thanks, Emily, these were great solutions.


chipjack

unread,
Jul 3, 2007, 8:05:49 PM7/3/07
to
On Jul 3, 6:01 pm, Emily Short <emsh...@mindspring.com> wrote:
> <code>
> After reading a command:
> repeat through the Table of Numerical Substitution
> begin;
> if the player's command includes topic entry, replace the matched
> text with the replacement entry;
> end repeat.
>
> Table of Numerical Substitution
> topic replacement
> "one" "1"
> "two" "2"
> "three" "3"
> "four" "4"
> "five" "5"
> "six" "6"
> "seven" "7"
> "eight" "8"
> "nine" "9"
> "ten" "10"
> </code>

Emily,

I tried something similar to this a while back, and ended up with code
that compiled, but crashed whatever interpreter it ran on. That's what
happens if you use anything other than 'topic' as the column name in
the table.

What's so special about the "topic" column? Are there rules about this
that we ought to be following?

Thanks,
Chipjack

Emily Short

unread,
Jul 3, 2007, 8:27:19 PM7/3/07
to

Text in the topic column can be compared against player input; text in
other kinds of column can be printed out. Inform stores text-to-print
and text-to-compare-to-input differently.

The reason for this has to do with stuff about the z-machine that I've
never looked into very deeply, I'm afraid; someone else would have to
explain the underlying technical reasons, if you're interested in
them.

chipjack

unread,
Jul 6, 2007, 9:00:21 PM7/6/07
to
On Jul 3, 8:27 pm, Emily Short <emsh...@mindspring.com> wrote:
> The reason for this has to do with stuff about the z-machine that I've
> never looked into very deeply, I'm afraid; someone else would have to
> explain the underlying technical reasons, if you're interested in
> them.

I get it now. Thanks!

-- Chipjack

Emily Short

unread,
Jul 11, 2007, 3:46:37 AM7/11/07
to
On Jul 4, 12:20 am, Sami <hbaf...@yahoo.com> wrote:

> <code>
> Playing nim is an action applying to one number. Understand
> "[number]" and "take [number]" and "take [number] counter" and "take
> [number] nim counter" and "take [number] counters" and "take [number]
> nim counters" as playing nim.
>
> Carry out playing nim:
> if the number understood is less than 1, say "[wrong number response]"
> instead;
> if the number understood is greater than 5, say "[wrong number
> response]" instead;
> [snip rest of rule as not applicable here]
>
> To say wrong number response: say "You must take 1 to 5 counters."
> </code>

Just for what it's worth, I have tried this in a couple of different
scenarios (of other objects in the game), and I can't seem to get it
to produce the bug you describe. So I'm not sure what to tell you here.

Sami

unread,
Jul 12, 2007, 12:13:08 PM7/12/07
to

Well, you'd have to magically hit on a number that happens to be
assigned to another object in your game. For me, 63 is apparently
assigned to the wooden box. It's not random, because it's 63 every
time I compile it. I've never hit on any other objects, though, so
maybe in general the object numbers are higher than 100?

I can send you my entire source code if you really want to see the bug
in action... let me know and I'll e-mail it to you.

James Jolley

unread,
Jul 12, 2007, 12:52:57 PM7/12/07
to
Hi there,

I'd like to see it in action because it's certainly very odd isn't it!

Feel free to email if you want too.

-James-

In article <1184256788.7...@k79g2000hse.googlegroups.com>,
hba...@yahoo.com says...


----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms at!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----

Emily Short

unread,
Jul 16, 2007, 4:48:05 AM7/16/07
to

Sure, if you like. It may take me a couple of days to get around to
looking at, but if it's an Inform bug we should work out why.

Hector Rodriguez

unread,
Jul 17, 2007, 3:35:31 AM7/17/07
to

> Text in the topic column can be compared against player input; text in
> other kinds of column can be printed out. Inform stores text-to-print
> and text-to-compare-to-input differently.
>
> The reason for this has to do with stuff about the z-machine

Am I the only person who finds this to be a major limitation? Why
remain so attached to the z-machine, then, instead of just developing
an alternative interpreter?


Emily Short

unread,
Jul 17, 2007, 6:18:37 AM7/17/07
to

Note: this is not an official answer because I didn't make this
decision. But:

Developing an alternative interpreter is not a minor thing that one
can "just" do: it usually takes at least a couple of years at a
minimum for the interpreter to be ported to a reasonable range of
platforms, and longer than that for marginal features -- multimedia
elements, e.g. -- to be implemented on all systems. And then there
tend still to be bugs and un-ironed-out kinks which make authors'
lives frustrating. Experience also suggests that anything produced for
a new interpreter gets fewer players than games produced for an
already-mainstream interpreter because some percentage of the playing
audience is reluctant to download new software; if you look back at
competition results, I think you'll find that the number of people
voting on new-interpreter games (whatever the new interpreter happens
to be in a given year) skews low. Moreover, interpreters at the beta-
stage tend to change functionality between releases, which means that
games compiled for early versions of the interpreter may stop running,
or run incorrectly, on later ones; this has happened to a few very
early TADS 3 games, and to some generations of ADRIFT.

The z-machine, by contrast, already exists for every desktop computer
in modern use and for quite a few antiques and handhelds; it can also
be run through a web browser. It has irritating features here and
there, but they're by and large well-understood irritating features.
It is unlikely to change its specifications dramatically from here.
Most z-machine interpreters have had enough use that any game-ruining
bugs have been found and squashed; the same is not true even for Glulx
and T3, which have been around for some years.

Besides this, the most serious irritations arise from the z-machine's
design for compactness, and from another perspective this is an asset:
it makes it possible to run the z-machine on portable devices where
various other virtual machines don't fit. As technology advances and
even portable machines are substantially more powerful than 1980s
desktop computers, that may cease to be such a big deal, but there is
still a portion of the playing population to whom it matters; if you
want to write IF that will be accessible to the very largest possible
number of people on the largest number of playing devices, the z-
machine is still what I would recommend. Any designer of a new
interpreter would also have to make some decisions about the relative
importance of speed, memory consumption, game file size, and power.

Having said that, what kinds of things are you finding to be seriously
limited by this restriction? You were recently describing doing
something with file input and searching a large body of text that
sounds to be well out of range of what Inform is designed to do, so
even a change of virtual machine might not resolve that problem. Are
there other things you have in mind?

Zylon

unread,
Jul 17, 2007, 6:34:18 AM7/17/07
to
"Hector Rodriguez" <smh...@cityu.edu.hk> wrote in message
news:1184657731....@m37g2000prh.googlegroups.com...

I'm not sure if it's worth anything, but this is one of the reasons I've
decided not to play around with Inform or the "z-machine." I find it to be a
wee bit of a relic. I suppose you could argue that about IF as a whole. I
get the whole "the z-machine is portable everywhere" argument but I don't
know how useful that truly is these days when the lines seem to mainly draw
at Mac and Win environments with a smattering of Linux thrown in. When I
work with the z-machine I just get this feeling of being left in the dust,
even though, admittedly, it's popular. But, like Paris Hilton, I think at
this point it's popular because it's popular rather than because it has
great advantages over competing systems.


DenizenOfShadows

unread,
Jul 17, 2007, 2:01:54 PM7/17/07
to
If you have a good story to tell and understand how a great piece of
IF works, I don't think it makes a difference if you use a platform
that's a bit of a relic. Your story isn't going to get any better
just because you make an upgrade :)

Michael Martin

unread,
Jul 17, 2007, 8:09:34 PM7/17/07
to
On Jul 17, 3:34 am, "Zylon" <zy...@hotmail.com> wrote:
> "Hector Rodriguez" <smh...@cityu.edu.hk> wrote in message
>
> news:1184657731....@m37g2000prh.googlegroups.com...
>
> >> Text in the topic column can be compared against player input; text in
> >> other kinds of column can be printed out. Inform stores text-to-print
> >> and text-to-compare-to-input differently.
>
> > Am I the only person who finds this to be a major limitation?

Probably not; the String Buffer extension exists in large part to
close the gap. Of course, once closed, it's not much of a limitation
anymore.

> I'm not sure if it's worth anything, but this is one of the reasons I've
> decided not to play around with Inform or the "z-machine."

Inform, of course, also targets Glulx, a full 32-bit VM that's roughly
as compatible as TADS 3. If you want to have your stuff run on
people's Palm Pilots, you'll need to target a restricted machine, as
always.

>I find it to be a
> wee bit of a relic. I suppose you could argue that about IF as a whole.

Then you're *clearly* in the wrong newsgroup.

> When I
> work with the z-machine I just get this feeling of being left in the dust,
> even though, admittedly, it's popular.

What exactly are you trying to do with it that's hitting limitations?
I've been working on an enormously sprawling WIP for quite a while now
in I7 and I'm still not even close to hitting the .z8 limitations, to
say nothing of fundamental Z-Machine Limitations. This, however,
*does* seem to be a fairly unique experience, and I'm really curious
what it is that I'm doing differently. (Or even people who were
writing fairly small works and found they had to bump up to .z8; I was
at roughly 35,000 words of source text before I got kicked into .z8
land, and that seems to be completely unheard-of.)

--Michael

Hector Rodriguez

unread,
Jul 17, 2007, 11:19:41 PM7/17/07
to
Thanks for the response, Emily. I appreciate the portability and
compactness of the z-machine. Here are some issues I have been having
trouble with:

#1. Allowing the player to enter input on multiple windows (this can
be done with glulx, although it takes considerable effort to set up,
so it is not a major irritation).
#2. Manipulating player commands (storing, concatenating, comparing,
and otherwise doing stuff with strings storing player inputs). This
can be done with Inform 6, but it is difficult with I7, and remains
somewhat of a pain even with I6. I guess the string buffers extension
takes care of this, though, but I have not explored its capabilities
at great length yet.
#3. Mining data from files and from the www during play.
#4. Support for regular expressions (which is useful in the context of
#2 and #3). I have looked at TADS 3, which appears to have excellent
support for regex work. In fact, it seems to me to offer better
support for most of the points I am listing here, but I am only a
beginner at the moment.
#5. The inability of I7 to say topic entries. I am used to this by
now, but it remains somewhat of an irritation.

All of these requests seem to me to be fairly reasonable extensions of
the idea of the interactive fiction. Please correct me if some of them
are not really problems for the z-machine. I *really* enjoy coding in
I7, and would like to continue working with it, but it does feel too
constraining at times.

BTW, is the z-machine substantially more portable than the TADS
interpreter? I am really ignorant when it comes to this.

Thanks again.

Message has been deleted

José Manuel García-Patos

unread,
Jul 18, 2007, 1:59:07 PM7/18/07
to

> The z-machine, by contrast, already exists for every desktop computer
> in modern use and for quite a few antiques and handhelds; it can also
> be run through a web browser. It has irritating features here and
> there, but they're by and large well-understood irritating features.

The keyword here is not «well-understood» but «irritating». What I
mean is that this is a very reactionary point of view. People are not
asking for a revolution («Let's end with the Z-machine now!») but for an
evolution («If it takes two or three years to build interpreters for a
new VM, why don't we start working on it now with a 21st century mindset
so we can gradually abandon the limitations of the Z-machine?»). I don't
think it's an unreasonable claim. The Z-machine has given a great service
to the community, and it will never cease to be used. (There are too many
great games written for it.) But it is limited and outdated as far as
today's needs for game development go. That, I think, is a fact.

All The Best.
José Manuel García-Patos
Madrid

James Jolley

unread,
Jul 18, 2007, 2:43:04 PM7/18/07
to
Hi,

To be honest, you can compile to glulxe so it doesn't really matter all
that mutch.

In article <pan.2007.07.18....@alumno.uned.es>, jgarciapa3
@alumno.uned.es says...


>
> > The z-machine, by contrast, already exists for every desktop computer
> > in modern use and for quite a few antiques and handhelds; it can also
> > be run through a web browser. It has irritating features here and
> > there, but they're by and large well-understood irritating features.
>

> The keyword here is not «well-understood» but «irritating». What I


> mean is that this is a very reactionary point of view. People are not

> asking for a revolution («Let's end with the Z-machine now!») but for an
> evolution («If it takes two or three years to build interpreters for a


> new VM, why don't we start working on it now with a 21st century mindset

> so we can gradually abandon the limitations of the Z-machine?»). I don't


> think it's an unreasonable claim. The Z-machine has given a great service
> to the community, and it will never cease to be used. (There are too many
> great games written for it.) But it is limited and outdated as far as
> today's needs for game development go. That, I think, is a fact.
>
> All The Best.

> José Manuel García-Patos
> Madrid
>
>


---- Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ----


Get Anonymous, Uncensored, Access to West and East Coast Server Farms at!

---- Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ----

José Manuel García-Patos

unread,
Jul 18, 2007, 4:37:57 PM7/18/07
to

> To be honest, you can compile to Glulx so it doesn't really matter all
> that much.

To be honest, I don't think Glulx is the answer, either. Others have given
reasons for this (even in this same thread if I remember correctly) that
I share, so I won't repeat them here. Personally, I always thought of
Glulx as nothing but a patch. But this is just my opinion, and I don't
even think anyone else should share it.

James Jolley

unread,
Jul 18, 2007, 4:51:28 PM7/18/07
to
Hi,

I myself have never really used Glulxe but as I understood it, it lifts
Z machine limits so I thought I was being helpful. Please correct me
folks if I have it all wrong.


In article <pan.2007.07.18....@alumno.uned.es>, jgarciapa3
@alumno.uned.es says...
>

Zylon

unread,
Jul 18, 2007, 5:45:13 PM7/18/07
to
"James Jolley" <james....@btinternet.com> wrote in message
news:MPG.21086f96b...@News-West.newsgroups.com...
Hi,

> To be honest, you can compile to glulxe so it doesn't really matter all
> that mutch.

I'm curious about this as well. I notice everyone brings up Glulx when they
talk about the z-machine. From what I can see, Glulx is largely but not only
a sort of "add-on" to the z-machine. I know it's a new VM so it's
technically not an add-on in that sense. But if the VM is so much better,
why not move to that? Why not start only compiling games to Glulx? Why do
people still keep compiling to the z-machine? I keep seeing Glulx get
mentioned but beyond getting past a few memory and object limitations with
the z-machine, I don't see what it's main draw is. Clearly the z-machine was
outdated a bit and that's why Glulx was put in place. Is that right? If not,
what was the motivation?


José Manuel García-Patos

unread,
Jul 18, 2007, 5:55:10 PM7/18/07
to

> I myself have never really used Glulx but as I understood it, it lifts
> Z-machine limits so I thought I was being helpful. Please correct me
> folks if I have it all wrong.

As far as I know (but I'm no expert) you were right. I didn't mean to say
otherwise. It's just that the Z-machine limits I was thinking of were not
the same that Glulx lifted. I will always admit Glulx was an improvement
over the Z-machine, but in the same way a patch is an improvement over a
previous version of a program. I don't think it made a real difference. At
least not in the aspects I care more about, and about whom I have written
extensively already.

Andrew Plotkin

unread,
Jul 18, 2007, 6:32:21 PM7/18/07
to
Here, Zylon <zyl...@hotmail.com> wrote:
> "James Jolley" <james....@btinternet.com> wrote in message
> news:MPG.21086f96b...@News-West.newsgroups.com...
> Hi,
>
> > To be honest, you can compile to glulxe so it doesn't really matter all
> > that mutch.
>
> I'm curious about this as well. I notice everyone brings up Glulx when they
> talk about the z-machine. From what I can see, Glulx is largely but not only
> a sort of "add-on" to the z-machine. I know it's a new VM so it's
> technically not an add-on in that sense. But if the VM is so much better,
> why not move to that? Why not start only compiling games to Glulx?

It offers specific advantages, which are primarily about game size.[*]
It also has specific disadvantages: execution is somewhat slower, and
there aren't interpreters for nearly as many platforms.

So it doesn't make sense for every Inform game to be released as
Glulx, but it is a reasonably clean upgrade path for an Inform game
that grows beyond a certain point. (You might need a library extension
to be ported, but that's tedious at worst, not difficult.[*])

You can fairly call Glulx an "add-on", in this sense: its primary
design goal was for Inform to compile to it, without the size limits
of the Z-machine. And Inform's original design goal, as a language,
was to compile to the Z-machine. So a lot of the VM structure is
similar. That was inevitable. (Rewriting Inform to compile to, say, the
TADS-3 VM would have been *much* more work -- unless you took the
route of writing a Z-code interpreter *in* TADS, which would not give
you any new functionality.)

So Glulx was intended to give Inform more space to grow in, but it was
not intended to make Inform a more powerful *language*. That was a
separate problem. And this proved to be a valid choice, because I7
came along next, and that was a redesign of the language which was
independent of the VM (except for size issues).

However, you do still run into underlying assumptions of the language
-- like the string handling -- which I perpetuated from Z-code into
Glulx, because the assumptions of the language were what I needed to
support.

[* And sound/graphics, but that's just beginning to filter into the I7
development system.]

[* Except, again, for display stuff like graphics. My hope is that the
greater differences of Glulx in that area will be a win in the long
term.]

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're innocent.

greg

unread,
Jul 18, 2007, 9:46:06 PM7/18/07
to
Andrew Plotkin wrote:
> However, you do still run into underlying assumptions of the language
> -- like the string handling -- which I perpetuated from Z-code into
> Glulx, because the assumptions of the language were what I needed to
> support.

And so the cycle continues. I7 is molded by the limitations
of the VM that it targets, and the evolution of the VM is
constrained by the assumptions of I7. Etc.

The main problem I see with the Z-machine and Glulx is that
they're too low-level. They expend their energy messing
around with bits and bytes when they should be dealing
with higher-level concepts like objects and strings.

Necessity for fitting into a small machine is often cited
as a justification for this low-level nature, but I don't
believe that. There were Logo interpreters for the Apple
II, and a Logo VM is much more like a Lisp machine than
a Z-machine. The Z-code interpreters for 8-bit micros
dealt with the size problem by paging, and a high-level
interpreter can do that just as well as a low-level one.

--
Greg

John W. Kennedy

unread,
Jul 18, 2007, 10:12:24 PM7/18/07
to
greg wrote:
> Andrew Plotkin wrote:
>> However, you do still run into underlying assumptions of the language
>> -- like the string handling -- which I perpetuated from Z-code into
>> Glulx, because the assumptions of the language were what I needed to
>> support.

> And so the cycle continues. I7 is molded by the limitations
> of the VM that it targets, and the evolution of the VM is
> constrained by the assumptions of I7. Etc.

> The main problem I see with the Z-machine and Glulx is that
> they're too low-level. They expend their energy messing
> around with bits and bytes when they should be dealing
> with higher-level concepts like objects and strings.

You have just demonstrated that you haven't any idea of what you're
talking about. Read the Z-machine and Glulx specs or shut up.
--
John W. Kennedy
"The pathetic hope that the White House will turn a Caligula into a
Marcus Aurelius is as naīve as the fear that ultimate power inevitably
corrupts."
-- James D. Barber (1930-2004)

Zylon

unread,
Jul 18, 2007, 10:49:28 PM7/18/07
to
"John W. Kennedy" <jwk...@attglobal.net> wrote in message
news:cMzni.30$aM6...@newsfe12.lga...

> You have just demonstrated that you haven't any idea of what you're
> talking about. Read the Z-machine and Glulx specs or shut up.

So helpful, John, thanks. For my part, I have read the specs and in some
respects I agree with Greg. I do see the design of the z-machine being from
a time when memory, processing speed, and storage space were very limited
and when too many assumptions couldn't be made. Further, the growth had to
be augmented based on those changes, hence what I consider the messy use of
opcodes. I tend to agree with Greg in the sense that I see the limitations
of the z-machine (some of the more conceptual limitations, that is) being
perpetuated into Glulx. So regardless of some of the low-level limitations
that Glulx helps you get around, you're still stuck with some of the
higher-level limitations. One that I often see is how much you can deal with
the parser in terms of overriding it without getting massively complicated.
Or the limited ways that entry points can effectively be used, again unless
you want to get overly complicated.

Part of what I'm talking about here is the language and not the VM but the
VM seems to impose a bit on what the language supports. If that's not the
case, then I'm wondering why the T3 VM is clearly more powerful than the
z-machine VM and so is the language. Regardless of whether or not you like
TADS or Inform, the common sentiments are that TADS is more powerful but has
a steeper learning curve and isn't as widely ported. At least that's what
I've seen when people bring this stuff up.


Hector Rodriguez

unread,
Jul 18, 2007, 10:57:32 PM7/18/07
to
I wrote a message yesterday that seems to have disappeared (or rather,
never appeared). So let me try to reproduce it.

I really appreciate the work that's gone into preparing I7, and I
really enjoy using it. I have recommended it to my students, and their
response has been, on the whole, very positive. I7 is a great system
for most projects that adhere to the Infocom model. But here are some
tasks that are difficult to tackle with this system. Perhaps this is
due to my ignorance, rather than any intrinsic limitations of the z-
machine, so I apologize in advance:

#1. Multiple windows, each of which accepts player commands (but this
can be done with glulx, although with considerable effort, so it is
not a problem).
#2. Storing and manipulating player input. This is (as far as I can
see) vritually impossible in I7, but it can be done with String
Buffers so, again, not a major problem. String manipulation
nonetheless remains relatively difficult and limited, compared for
instance to Processing and other systems designed to be used by
artists.
#3. Data mining from files and from the internet.
#4. Better support for regular expressions, something like the
java.util.regex engine. (Points #2 and #4 would facilitate task #3, so
perhaps all of this is related.)

In addition, the restrictions on saying Topic entries take some
getting used to. (I assume I will eventually get used to it, but I
often want to insert the statement 'say "[topic entry]";'...).

Of course, one could just argue that the z-machine was designed for a
very specific genre, and that all of the above requests fall outside
the specific domain for which Inform 7 was intended, an argument which
I can of course see. Perhaps one should simply adjust oneself to the
limitations of the medium: This is certainly a reasonable response.
But the points above all seem to enhance (rather than undermine) the
evolution of text-based interactive fiction, and I wish I could take
I7 in those directions.

It might be that coding in I7 *is* so enjoyable that I wish I could
use it to do all I want, which is certainly *my* problem...

I really hope this message is understood as a constructive one, not as
an attempt to criticize people who have put lots of effort to make a
product that can be shared by the entire community.

BTW, has anyone ever thought of porting I7 to the JVM? Is this a
stupid question? I mean, I guess I7 is not necessarily tied to the
limitations of the z-machine, and the power of the JVM could open up
new directions.

Adam Thornton

unread,
Jul 18, 2007, 11:25:01 PM7/18/07
to
In article <pan.2007.07.18....@alumno.uned.es>,
José Manuel García-Patos <jgarc...@alumno.uned.es> wrote:

>The keyword here is not «well-understood» but «irritating». What I


>mean is that this is a very reactionary point of view. People are not

>asking for a revolution («Let's end with the Z-machine now!») but for an
>evolution («If it takes two or three years to build interpreters for a


>new VM, why don't we start working on it now with a 21st century mindset

>so we can gradually abandon the limitations of the Z-machine?»).

Wouldn't that be, er, Glulx?

Adam

Emily Short

unread,
Jul 19, 2007, 7:11:00 AM7/19/07
to
Google Groups appears to be posting everything with a day or so of lag
right now, so apologies if someone else has spoken to these points and
I'm just not seeing it yet. But:

> #1. Allowing the player to enter input on multiple windows (this can
> be done with glulx, although it takes considerable effort to set up,
> so it is not a major irritation).
> #2. Manipulating player commands (storing, concatenating, comparing,
> and otherwise doing stuff with strings storing player inputs). This
> can be done with Inform 6, but it is difficult with I7, and remains
> somewhat of a pain even with I6. I guess the string buffers extension
> takes care of this, though, but I have not explored its capabilities
> at great length yet.

String Buffers lets you do things like change player input into a
string that can be stored and printed; allowing the player to name
objects in the game; etc. It's not powered with extensive fancy
routines to perform on the player's input, but it may be adequate for
what you need; I don't know.

> #3. Mining data from files and from the www during play.

Several people have asked me about this since I7 was released; it's an
interesting case of an expectation that newcomers have which veteran
IF authors don't share as much, because IF traditionally doesn't do
this kind of thing often/at all. There are a few old systems (e.g.
Eamon) that would store character data in a file to be transferred
from one IF scenario to another, and while Glulx has some limited file
I/O abilities, I think they were mostly intended for that kind of
use.

Another possible catch: in general, IF systems tend to be designed to
reduce the possibility of malicious use -- the virtual machine isn't
allowed to do very much to/with the host computer, so that you can be
sure that in running an unknown .z5 file you're taking no risks. I
seem to recall reading that one of the TADS VMs is a bit more flexible
and has several levels of security which can be set by the player,
which may be a bit closer to what you would like (though off the top
of my head I can't think of a single TADS game that does much by way
of writing external files or launching outside applications; I also
don't remember whether this was said about TADS 2, TADS 3, or both).
The security precaution makes great practical sense if your
distribution model is that players will download and play on their own
computers files produced by unknown and unverifiable authors. It makes
rather less sense if you envision writing something to be run
exclusively on a host computer and accessed by players either via an
online connection or as part of an exhibition.

That said, it's very interesting to me that several people see this as
a direction in which they'd like to take IF and find the tools
currently lacking, so I'd be curious to hear more about what you want
to do and what facilities you'd need to support it.

Would it be possible (e.g. in the case of your Poe idea) to have some
other script work over your data for you and perhaps produce a sort of
concordance file which would then be sufficiently manipulated for
Glulx to read it in and make simple use of it?

Or: would it be possible to go with the host machine/play online model
for your game, rather than something to be distributed to players? I
can imagine that if you were writing a game to be run on a host
computer and used via online connection, you might be able to
supplement the abilities of your game file with some scripts that ran
on the host machine: for instance, when the player started up a new
game, the script might go out and pull the needed files from the web
and run some perl/python/whatever on them to make the content ready
for the game itself to use.

Largely brainstorming here, but I would guess there are at least
partial ways around these issues.

> #4. Support for regular expressions (which is useful in the context of
> #2 and #3). I have looked at TADS 3, which appears to have excellent
> support for regex work. In fact, it seems to me to offer better
> support for most of the points I am listing here, but I am only a
> beginner at the moment.

That is indeed likely.

> #5. The inability of I7 to say topic entries. I am used to this by
> now, but it remains somewhat of an irritation.

Mmyeah. Well, again, topic entries can sometimes be things like

topic
"george" or "fred"
"[puking pastilles]"
"argus/filch"

...in which case, data-storage-type aside, it's not quite clear what
you'd be printing. The first string of text that corresponds to what
the topic would in theory be able to match? Conceivable, but I think
it would get ugly fast.

> BTW, is the z-machine substantially more portable than the TADS
> interpreter? I am really ignorant when it comes to this.

I believe so: I don't know of any TADS 3 interpreter that can be
hooked up for online play through a web browser (though there is one
for TADS 2); I also haven't heard much about T3 running successfully
on handheld devices. On the other hand, if you're looking to do
extensive processing and www -access from within your game, you
probably aren't targeting handhelds anyway.

John W. Kennedy

unread,
Jul 19, 2007, 12:59:32 PM7/19/07
to
Zylon wrote:
> "John W. Kennedy" <jwk...@attglobal.net> wrote in message
> news:cMzni.30$aM6...@newsfe12.lga...
>
>> You have just demonstrated that you haven't any idea of what you're
>> talking about. Read the Z-machine and Glulx specs or shut up.
>
> So helpful, John, thanks. For my part, I have read the specs and in some
> respects I agree with Greg.

You agree that they don't support strings or objects?

--
John W. Kennedy
"Though a Rothschild you may be
In your own capacity,
As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
So you start another company to-morrow!"
-- Sir William S. Gilbert. "Utopia Limited"

Andrew Plotkin

unread,
Jul 19, 2007, 2:41:44 PM7/19/07
to
Here, greg <gr...@cosc.canterbury.ac.nz> wrote:
> Andrew Plotkin wrote:
> > However, you do still run into underlying assumptions of the language
> > -- like the string handling -- which I perpetuated from Z-code into
> > Glulx, because the assumptions of the language were what I needed to
> > support.
>
> And so the cycle continues. I7 is molded by the limitations
> of the VM that it targets, and the evolution of the VM is
> constrained by the assumptions of I7. Etc.

I was talking about assumptions, not limitations. They live in the
same zoo, but they're not the same animal.

(Okay, even the same cage sometimes.)



> The main problem I see with the Z-machine and Glulx is that
> they're too low-level. They expend their energy messing
> around with bits and bytes when they should be dealing
> with higher-level concepts like objects and strings.

That's the sort of design assumption which can, and is, fixed by
library code. The "cost" of messing with bytes was critical in 1980.
Now it's faded into the cracks of the library overhead, which is
dominated by higher-level algorithms -- managing rule lists,
graph-walking -- which are the same in any VM or language.

> Necessity for fitting into a small machine is often cited
> as a justification for this low-level nature

The line about "the Z-machine was designed for small computers" gets
flung around a lot in these discussions. It's neither the reason for
everything, nor the point that always needs to be refuted.

When we're talking about dynamic types and string manipulation, the
relevant Z-machine feature is the fixed memory space. There is no
notion of allocating or freeing objects. That's not a limitation that
Infocom stumbled into blindly -- as Lisp hackers, they would have felt
that consing up new objects was the heart of programming. But it made
sense given the small (and slow) target platforms of the time.

This led to a *design* model which ZIL and Inform share, where dynamic
text output comes from functions, rather than from strings dynamically
assembled by functions. And this has proven effective in IF.

Now, Glulx *does* have a notion of memory allocation, and there are
dynamic string libraries that make use of it. This form of string has
not been back-ported homogenously throughout the Inform library --
it's an extension which is available for use. That's untidy, but it's
not a limitation; it's the result of work to relieve limitations.

(Possibly the next language will take a more dynamic approach to
string and object handling from the core, and still use Glulx as a
target. Possibly not. That problem is in the future. :)

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

It's a nice distinction to tell American soldiers (and Iraqis) to die in
Iraq for the sake of democracy (ignoring the question of whether it's
*working*) and then whine that "The Constitution is not a suicide pact."

Andrew Plotkin

unread,
Jul 19, 2007, 2:43:34 PM7/19/07
to
Here, Andrew Plotkin <erky...@eblong.com> wrote:
>
> This led to a *design* model which ZIL and Inform share, where dynamic
> text output comes from functions, rather than from strings dynamically
> assembled by functions. And this has proven effective in IF.

While also, I should add, ensuring that Inform makes a terrible
replacement for Perl.

Brian Slesinsky

unread,
Jul 20, 2007, 3:28:14 AM7/20/07
to
On Jul 18, 6:46 pm, greg <g...@cosc.canterbury.ac.nz> wrote:
> And so the cycle continues. I7 is molded by the limitations
> of the VM that it targets, and the evolution of the VM is
> constrained by the assumptions of I7. Etc.

It's actually quite similar to the evolution of x86 processors. Lots
of people tried to replace the x86 architecture and failed (including
Intel), because backward compatibility wins. And yet, everyone seems
to like their new computers just fine.

> The main problem I see with the Z-machine and Glulx is that
> they're too low-level. They expend their energy messing
> around with bits and bytes when they should be dealing
> with higher-level concepts like objects and strings.

Well, people tried to write Lisp machines and eventually abandoned
them because general-purpose processors were faster. IBM tried to
beat Intel using the much cleaner PowerPC architecture, but x86
architecture just has more resources behind it, so eventually even
Apple switched.

Switching to a cleaner architecture doesn't solve anything other than
making things possibly easier for compiler and interpreter writers at
some far-off future date, at the cost of much more work in the
meantime. The only real things to complain about are limitations
visible in high-level languages, such as the special case of the
"topic" column. Fixing limitations, even if it means that you
sacrifice some portability if you use the new feature, is a better way
to make progress.

- Brian

greg

unread,
Jul 21, 2007, 10:59:03 PM7/21/07
to
John W. Kennedy wrote:
> You have just demonstrated that you haven't any idea of what you're
> talking about. Read the Z-machine and Glulx specs or shut up.

I have actually read the Z-machine spec in considerable
detail, so I have quite a good idea what I'm talking about
in that area, and from what I know of Glulx, it is not
very different in kind -- as Andrew has said, it can't be,
or Inform wouldn't compile to it so easily.

I'm also very familiar with the Python VM, which is what I
would call an example of a high-level VM. There is an enormous
difference between them. The Z-machine is very much closer to
a hardware machine language than the Python VM.

Sure, the Z-machine has "objects", but they're a poor thing
compared to what Python means by an "object". The Z-machine
has no built-in notions of dynamic strings, lists, mappings,
etc. You can implement them on top of the Z-machine, but it's
tedious, and not very efficient because it's all being
interpreted.

--
Greg

greg

unread,
Jul 21, 2007, 11:35:59 PM7/21/07
to
Andrew Plotkin wrote:

> When we're talking about dynamic types and string manipulation, the
> relevant Z-machine feature is the fixed memory space. There is no
> notion of allocating or freeing objects.

Also very nearly no notion of high-level data types.

> This led to a *design* model which ZIL and Inform share, where dynamic
> text output comes from functions, rather than from strings dynamically
> assembled by functions. And this has proven effective in IF.

I would say it has proved *adequate*, in the sense that
we've been able to get by with it, except in those areas
where we can't, and then we use various workarounds.

Also, I think that talking about text output in relation
to dynamic strings misses the point somewhat. Even in TADS,
most output is generated by functions printing out literal
text, so this isn't really where the motivation for dynamic
data structure arises.

One fairly obvious place where it does arise is in the
parser. You don't know how many words the player is going
to use in his command, or how long the words are going to
be. Also you want to be able to process the words in flexible
ways, such as chopping out a sublist and passing it off to
something that searches for matching objects. All this is
greatly simplified if you have dynamic list and string data
types.

Then there are occasions when you really would like to
generate objects dynamically, so you don't have to come
up with some reason why you can't e.g. get more than 10
jelly beans out of the jelly bean dispenser.

I know that all these things can theoretically be implemented
on top of the Z-machine, and woven into the I7 language, given
enough effort. But the practical fact of the matter is that
they *haven't*, and probably won't be any time soon, due to
the amount of effort required.

If the Z-machine had provided dynamic lists and strings from
the outset, none of this effort would have been necessary,
and the development of I7 would have been further ahead
by now. So it seems to me that, whether you call them
"limitations" or "features" or whatever, some characteristics
of the Z-machine *have* held back the development of I7.

--
Greg

greg

unread,
Jul 22, 2007, 12:12:37 AM7/22/07
to
Brian Slesinsky wrote:

> It's actually quite similar to the evolution of x86 processors.

In terms of the architecture being entrenched, yes,
some of the same forces are at work. But I'm not sure
that's the only reason for the rise of the x86 kludge
tower. Given how easily Apple managed to switch from
the PPC to x86, I'm not sure that CPU architecture
entrenchment is much of an issue any more. I suspect
that Intel being greedy corporate bastards, NIH, etc.
have at least as much to do with it.

> Well, people tried to write Lisp machines and eventually abandoned
> them because general-purpose processors were faster.

That's not really the same thing. The Lisp machine was
trying to implement Lisp in hardware, and hardware
development is extremely expensive. If Lisp Machines Inc.
had had the same resources as Intel put into the Pentium,
the Lisp machine would probably be the fastest thing at
executing Lisp today (although slower at executing
anything else).

But we're talking about a VM implemented in software,
which is a vastly easier thing to develop until it's
as good as it can be. We're not going to get overtaken
by someone who can program 1000 times better than we
can.

> Switching to a cleaner architecture doesn't solve anything other than
> making things possibly easier for compiler and interpreter writers at
> some far-off future date,

I think the benefits are more certain than that. By working
at a higher level of abstraction, compiler writers would be
freed from wrestling with low-level details and have more
time and energy available to devote to important things like
developing the language and the conceptual models behind it.
And library authors wouldn't have to come up with things
like the String Buffer extension which provide partial
workarounds for shortcomings of the Z-machine.

There would be a cost to the switch, yes, but the cost will
only grow the longer the switch is put off. And if the
switch is never made, the benefits will never be obtained.

--
Greg

syzygy

unread,
Jul 22, 2007, 1:36:39 AM7/22/07
to
On Jul 21, 11:35 pm, greg <g...@cosc.canterbury.ac.nz> wrote:
> Andrew Plotkin wrote:
> > When we're talking about dynamic types and string manipulation, the
> > relevant Z-machine feature is the fixed memory space. There is no
> > notion of allocating or freeing objects.
>
> Also very nearly no notion of high-level data types.

But higher-level data types can be implemented out of lower ones. For
instance, I7 creates relations (James Bond loves all women. Frost does
not love Bond., etc) on top of Z-machine features.

However, the implementation of relations is more costly in both time
and space than it would be using dynamic allocation. The latter seems
to me to be a fair complaint.

> Also, I think that talking about text output in relation
> to dynamic strings misses the point somewhat. Even in TADS,
> most output is generated by functions printing out literal
> text, so this isn't really where the motivation for dynamic
> data structure arises.
>
> One fairly obvious place where it does arise is in the
> parser. You don't know how many words the player is going
> to use in his command, or how long the words are going to
> be.

Do people really enter commands of more than 100 characters max?

Even Unix did okay for itself for 20+ years, despite having a fixed
command line length. I think many shells still have a limit, although
I could be wrong.

> Also you want to be able to process the words in flexible
> ways, such as chopping out a sublist and passing it off to
> something that searches for matching objects. All this is
> greatly simplified if you have dynamic list and string data
> types.

Personally, I'd rather the parser just told me what action was taking
place, and not have to process the input myself. Although I can
imagine some complicated conversation model where complicated string
handling would be useful.

> Then there are occasions when you really would like to
> generate objects dynamically, so you don't have to come
> up with some reason why you can't e.g. get more than 10
> jelly beans out of the jelly bean dispenser.

If I only needed 3 jelly beans in the game, I'd be perfectly happy if
I got a message along the lines of: "You turn the dial on the
dispenser, but no jelly beans emerge. Looks like the machine is
jammed." In fact, I'd be happier, since I wouldn't waste time
collecting 25 jelly beans that I don't need.

Maybe a better example would be a game based on Hansel & Gretel, where
you have a loaf of bread that you can divide into arbitrary
breadcrumbs, which you can leave scattered in any room, on any
surface, etc. This sounds difficult to implement without dynamic
memory.


Andrew Plotkin

unread,
Jul 22, 2007, 6:04:46 PM7/22/07
to
Here, greg <gr...@cosc.canterbury.ac.nz> wrote:
>
> I know that all these things can theoretically be implemented
> on top of the Z-machine, and woven into the I7 language, given
> enough effort. But the practical fact of the matter is that
> they *haven't*, and probably won't be any time soon, due to
> the amount of effort required.

I agree. But it's not the effort of implementing them on top of the VM
-- Z-code or Glulx -- but rather the effort of implementing them
underneath the existing language. Changing all the string handling in
Inform 7 to dynamic string objects is a nice idea, but it doesn't
become easy just because someone has handed you a functional string
class.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.

Zylon

unread,
Jul 22, 2007, 6:35:52 PM7/22/07
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:f80k9u$dlr$1...@reader2.panix.com...

> I agree. But it's not the effort of implementing them on top of the VM
> -- Z-code or Glulx -- but rather the effort of implementing them
> underneath the existing language. Changing all the string handling in
> Inform 7 to dynamic string objects is a nice idea, but it doesn't
> become easy just because someone has handed you a functional string
> class.

This is interesting. So literally we're saying that the language is the
problem, not the VM. How much of a true overhaul would you say I7 is from
I6? I get the NL stuff but I'm talking about at a core level. Would it be
accurate to say that many of the limitations of implementing what you all
are discussing are truly carried over from I6?


greg

unread,
Jul 22, 2007, 8:45:06 PM7/22/07
to
syzygy wrote:
> But higher-level data types can be implemented out of lower ones.

Yes, but at a huge cost in efficiency. Interpreting
code is very expensive, so you want to get a decent
amount of stuff done by each VM instruction. E.g.
you want a "compare string" instruction, not a
"compare byte" instruction that you have to put in
a loop to compare strings. Etc.

> However, the implementation of relations is more costly in both time
> and space than it would be using dynamic allocation. The latter seems
> to me to be a fair complaint.

Yes, relations could be implemented very simply
and efficiently using something like a Python
dictionary as a basis.

> Do people really enter commands of more than 100 characters max?

Maybe not, but the time you spend thinking about
that number could be spent on something else. And
not just that number, but many others -- how many
words in the command? How many words in a noun
phrase? How many noun phrases?

And if you have to statically allocate these
buffers, then they're shared resources, and you
have to make sure two things don't both try to
use the same buffer at once.

Each one of these decisions on its own is not
a great burden, but when you have to make decisions
like this at every step, it adds up to a lot of
time and mental energy.

> Personally, I'd rather the parser just told me what action was taking
> place, and not have to process the input myself.

Someone had to write the parser in the first place.
If he didn't have to think about all the tedious
bookkeeping, he may have had time to make it a
better parser, or improve the library in other
ways. And sometimes you do want to manipulate the
input in ways that the parser author didn't
anticipate.

> Maybe a better example would be a game based on Hansel & Gretel, where
> you have a loaf of bread that you can divide into arbitrary
> breadcrumbs,

Something like that, yes.

I haven't played it myself, but I gather that Reliques
of Tolti-Aph has a place where you can get a message
something like "The game has run out of maze." Now that's
a mimesis-breaking statement if ever I heard one!

--
Greg

Ron Newcomb

unread,
Jul 25, 2007, 12:41:24 AM7/25/07
to
On Jul 3, 5:27 pm, Emily Short <emsh...@mindspring.com> wrote:
> Text in the topic column can be compared against player input; text in
> other kinds of column can be printed out. Inform stores text-to-print
> and text-to-compare-to-input differently.
>
> The reason for this has to do with stuff about the z-machine that I've
> never looked into very deeply, I'm afraid; someone else would have to
> explain the underlying technical reasons, if you're interested in
> them.

I'm presuming it works like that because a snippet is actually a list
of text pieces, ORed together. Remember, when you say:

Understand "hop" or "jump" or "skip" as jumping.

..you are defining one snippet, not three. The "or" that joins the
text pieces together is part of a snippet, and it's there even if
there's only one piece of text in the snippet.

Why "printing a snippet" isn't defined as printing the first bit of
text in the OR list is beyond me; perhaps because it just wasn't a
much-requested feature back in the day. It seems a trivial thing to
add.

--Ron

Reply all
Reply to author
Forward
0 new messages