Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!newsfeeds.belnet.be!news.belnet.be!news-hub.siol.net!zur.uu.net!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Glulx] branching to another function...
Message-ID: <GJDLJo.3ps@world.std.com>
Date: Sun, 9 Sep 2001 03:26:11 GMT
References: <e61ef191.0109081452.45f636f9@posting.google.com> <Pine.OSF.4.30.0109090247090.13491-100000@vesuri.Helsinki.FI> <GJDE6C.3Bn@world.std.com> <Pine.OSF.4.30.0109090421360.9295-100000@vesuri.Helsinki.FI>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 20
Xref: news.duke.edu rec.arts.int-fiction:92395

M Joonas Pihlaja  <jpihlaja@cc.helsinki.fi> wrote:
>Then again, assuming there's no deep *Glulx-VM-specific* reason
>for limiting branches to one function (compared to say an
>Inform-specific reason), I don't see why it should be dictated by
>the VM specification.  Especially as this issue is orthogonal to
>the rest of the spec.  The run-time system of the language being
>compiled is free to impose any additional constraints it likes on
>functions (say local-branches-only, or no stack variables, or
>whatever) but those kinds of constraints shouldn't be in the VM
>unless there's a good VM reason.

Well, yes and no. The VM discussed here is a specification, not an
implementation. One can imagine many possible implementations of a
specification. Narrowing the programs allowed by the specification
restricts choices to the compiler, but makes other implementations
of the interpreter more plausible. But again, I have no particular
clue about the specific reasoning behind this one aspect of Glulx;
but that might be me failing to imagine a possible implementation.

SeanB
