Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!feed2.news.rcn.net!rcn!netnews.com!xfer02.netnews.com!newsfeed1.cidera.com!Cidera!news-reader.ntrnet.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Glulx] branching to another function...
Message-ID: <GJDE6C.3Bn@world.std.com>
Date: Sun, 9 Sep 2001 00:47:00 GMT
References: <e61ef191.0109081452.45f636f9@posting.google.com> <GJDAxy.6pv@world.std.com> <Pine.OSF.4.30.0109090247090.13491-100000@vesuri.Helsinki.FI>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 42
Xref: news.duke.edu rec.arts.int-fiction:92391

M Joonas Pihlaja  <jpihlaja@cc.helsinki.fi> wrote:
>On Sat, 8 Sep 2001, Sean T Barrett wrote:
>> But allowing branches to common code from other functions is
>> NOT the thingg to change to get what you want.
>
>Why do you think this rule is in the spec?  It seems like an
>arbitrary and well-meaning one, but I fail to see the point.
>Care to educate me?  I sincerely would like to know.

Presumably Zarf has some reason but I wouldn't dare to guess what
he'd say, other than "It's intentional".

My rule of thumb is that there are two kinds of VMs, VMs
that simulate a very traditional Von Neumann machine
with code and data al intermixed, and function calls just
being branches that save things on the stack; the application
is free to mess around with things in a very unstructured
way.

At the other end are VMs like that found in Tads and Smalltalk
and such, in which the high-level structuring of the data tends to
be exposed to the VM itself, and in which a function defintion is
just another piece of data which means it needs to be well-contained.

The ZMachine is mostly of the first kind, but with built-in objects
and this "ZRegion" function that tries to determine from an address
which class of object it's looking at, it's slightly shifted in the
second direction. This particular aspect of Glulx sounds like it
goes further in the second direction, although Glulx as a whole
apparently has relatively unstructured memory.

I certainly don't see any good reason for it off the top of my head
in this particular case, since Glulx routines aren't going to be
participating in garbage collection or getting sneakily recompiled by
the interpreter, but those are the sorts of reasons one tends
to make branches local-routine-only. Or maybe Zarf just propogated
the rule down from high-level languages for no good reason and it would
be perfectly fine to change the spec. But with so many other options
at hand for solving the problem, messing with the spec at all seems
inappropriate.

SeanB
