Inform vs. TADS
John E
Ok guys,
I know this is a biggie.
But if you could please give me a good reason to choose
one over the other. I've been told that Inform has more of
a 'Infocomish' feel. From what I've seen of TADS is looks
a lot like C++. Is one easier to use? Would I lose any flexibility?
Which is better for beginners? I know basic programming, Pascal, and some
C.
Post a response or please e-mail
DELETE the word DELETE guys!!!
(of course ALAN looks good too ;> )
L. Ross Raszewski
In article <6iakap$h...@ecuador.earthlink.net>#1/1,
"John E" <johnDEL...@earthlink.net> wrote:
>
> Ok guys,
> I know this is a biggie.
>
> But if you could please give me a good reason to choose
> one over the other. I've been told that Inform has more of
> a 'Infocomish' feel. From what I've seen of TADS is looks
> a lot like C++. Is one easier to use? Would I lose any flexibility?
> Which is better for beginners? I know basic programming, Pascal, and some
> C.
>
Okay. If you know C, you've got a lot to unlearn . TADS is rigorously object
oriented, whereas Inform is object oriented, but its standard library is not.
This means, of course, that an inform game of much complexity is going to
break the OOP paradigm a little. Now, C and Pascal aren't OOP, so I don't
think that the nature of Inform's imperative style is going to gibe you too
much of a problem. If you're nuts about OOP, then TADS may be a better bet,
unless you're willing to wait a few months for the OOP inform library; Inform
code CAN be written as totally object oriented (well, you still need a Main()
function, but otherwise), once you overcome the legacy code in the library
Now, Inform does have some things on TADS; First, of course, it is more like
Infocom in look and feel. Second, it's parser is fully reprogrammable. ALso,
it has a much more sophisticated screen model. You won't see fancy multiple
line statuslines in TADS.
As close as I can tell (and I might be wrong) there are more contributed
libaries for inform-- extensions to the base libary allowing everything from
Invisiclues-style hints to ANSI-C style string functions (Heck, there are even
some libraries out there that I _haven't_ written)
On the other hand, TADS is not constrained by the size limitiations of the
Z-machine. (Though only a very few games have ever even approached the
Z-machine's size limit, and if there's a need (and if Zarf approves, though
why its up to him, I've no idea) Graham will add a new version of the
z-machine with a higher limit) Also, if you're doing graphics and sound,
while Inform's v6 allows much, much more flexibility, you'll still have to
wait a few months for a fully functional Blorb interpreter before including
graphics and sound with an inform game is practical. HTML tads does not
allow nearly as much control of the placement of graphics and the screen
model, but there is a runtime already available (of course, if cross-platform
portability is a big deal to you, you might even be better off with v6 and
blorb, as html tads is currently only win95, and at a guess, I'd say it'll be
about as long before we see it ported as it will until we see Blorb interps.)
Okay. Moral of the story time. I like inform. THere are also reasons to
choose tads, but if you're asking for opinions, I like inform. I'm not going
to try and act all unbiased and give a scientific explanation as to why one is
better than the other, because anyone who tries to doso is lying. Simply put,
inform is better suited than TADS to my own personal style of writing, and to
what I want to do in a game.
THanks.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Eric O'Dell
>Okay. If you know C, you've got a lot to unlearn . TADS is rigorously object
>oriented, whereas Inform is object oriented, but its standard library is not.
I've been using C for years, and I thought my knowledge of C was a
great boon in learning to program with TADS. The thing I had the most
difficulty getting used to is TADS' use of the Pascal-style assignment
and equality operators, which can now be toggled over to C-style
operators.
Objects in TADS are a heck of a lot less complex than objects in any
general-purpose OOP language I know. A TADS object is syntactically
and semantically very similar to a C struct with function pointers as
members, and really ought not to be too confusing to a C programmer.
>Now, Inform does have some things on TADS; First, of course, it is more like
>Infocom in look and feel. Second, it's parser is fully reprogrammable.
Well, in all fairness, so is the TADS parser. It just happens to be
reprogrammable in C. :)
>Okay. Moral of the story time. I like inform. THere are also reasons to
>choose tads, but if you're asking for opinions, I like inform. I'm not going
>to try and act all unbiased and give a scientific explanation as to why one is
>better than the other, because anyone who tries to doso is lying. Simply put,
> inform is better suited than TADS to my own personal style of writing, and to
>what I want to do in a game.
I like TADS better, but I must also confess that I like it in part
because of its close connection to C, and because I learned it first.
Dynamic object creation, which is pretty important to my current
project, seems to be easier in TADS. And now that MJR is actively
working on it again, there's all the more incentive for me to stay
put.
In an ideal world (you know, the one where we all have scads of free
time), the best way to choose between the two would be to design a
small but moderately complex sample adventure, and try coding it in
*both* TADS and Inform. And Hugo, Alan, and whatever else.
E.
Darin Johnson
> >Now, Inform does have some things on TADS; First, of course, it is more like
> >Infocom in look and feel.
First: What is this "Infocom in look an feel"? Isn't that an
incredibly silly issue? Both systems let you redefine the look and
feel don't they? The biggest difference is how inventory is
displayed, and that's trivial. I don't understand this issue at all...
er...@gadgetguru.com (Eric O'Dell) writes:
> > Second, it's parser is fully reprogrammable.
>
> Well, in all fairness, so is the TADS parser. It just happens to be
> reprogrammable in C. :)
What is it you can't do in TADS that someone would realistically want
to do? I did the Dungeon "ECHO" room with the TADS parser. It wasn't
nice, but the hooks were there to customize things. There's a routine
I think that can get called with the exact player input, and from
there you could use any language features on the input to parse it
(haven't done anything extensive with this, but theoretically...)
Also, I think the TADS parser is easier to use program with than
Inform, in an object oriented manner, which is very nice.
I know it's a silly argument, but I have multiple degrees in computer
science, and I seem to think it matters: The TADS language, despite
the glitches and warts, is esthetically more appealing than Inform.
Of course, the big reason for this is that the early Inform compilers
stayed close to the Z machine. That's pragmatics, and pragmatics are
good, but pragmatics aren't often esthetic.
Also, some have mentioned TADS doesn't have internationalization
support. But it does, sort of, depending upon what you mean.
Strings are 8-bit clean, so you can output in latin-1, latin3, or
in a multibyte code. You can also customize the parsing error
routines to give localized messages. I'm just reading from the manual
(2.1 release notes), but I haven't actually tried this.
> In an ideal world (you know, the one where we all have scads of free
> time), the best way to choose between the two would be to design a
> small but moderately complex sample adventure, and try coding it in
> *both* TADS and Inform. And Hugo, Alan, and whatever else.
And design the game *without* knowing TADS or Inform first! Then you
start noticing the gaps that one or the other language doesn't handle
well (ie, maximum number of properties, lack of parser support, how
hard it is to redesign the standard library to do things your way,
etc).
--
Darin Johnson
da...@usa.net.delete_me
Neil K.
Darin Johnson <da...@usa.net.removethis> wrote:
> First: What is this "Infocom in look an feel"? Isn't that an
> incredibly silly issue? Both systems let you redefine the look and
> feel don't they? The biggest difference is how inventory is
> displayed, and that's trivial. I don't understand this issue at all...
Plus, shouldn't we be breaking out of the Infocom mould? Striking off in
new and exciting directions? :)
> Also, some have mentioned TADS doesn't have internationalization
> support. But it does, sort of, depending upon what you mean.
> Strings are 8-bit clean, so you can output in latin-1, latin3, or
> in a multibyte code. You can also customize the parsing error
> routines to give localized messages. I'm just reading from the manual
> (2.1 release notes), but I haven't actually tried this.
I've tried it. Works fine. I have three versions of my game which can be
compiled for 8-bit Mac, 8-bit Windows and 7-bit everything else (eg:
UNIX). Pain in the arse, but there you go. However HTML-TADS understands
ISO Latin 1, and hopefully non-HTML TADS interpreters can be made to
understand whatever ISO Latin 1 codes are appropriate.
- Neil K
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Knothole
On Sat, 02 May 1998 00:31:08 GMT, Darin Johnson
<da...@usa.net.removethis> wrote:
>First: What is this "Infocom in look an feel"? Isn't that an
>incredibly silly issue? Both systems let you redefine the look and
>feel don't they? The biggest difference is how inventory is
>displayed, and that's trivial. I don't understand this issue at all...
I'm going to have to agree, and also agree with Neil's point that the
Infocom style is something we should be trying to progress beyond, or
at least build upon, rather than follow out of tradition or nostalgia.
>> In an ideal world (you know, the one where we all have scads of free
>> time), the best way to choose between the two would be to design a
>> small but moderately complex sample adventure, and try coding it in
>> *both* TADS and Inform. And Hugo, Alan, and whatever else.
>
>And design the game *without* knowing TADS or Inform first! Then you
>start noticing the gaps that one or the other language doesn't handle
>well (ie, maximum number of properties, lack of parser support, how
>hard it is to redesign the standard library to do things your way,
>etc).
That is an excellent point. The tools you use tend to create habits of
thought that can be quite limiting. Studying different tools, even if
you never intend to use them for anything significant, can give you a
new perspective on your favorite tools. I seldom use Perl or 80x86
assembly language or Forth, but what I learned from all three has had
a real beneficial impact on what I do with my tool of choice, C.
--Eric
Andrew Plotkin
Darin Johnson (da...@usa.net.removethis) wrote:
> > >Now, Inform does have some things on TADS; First, of course, it is more like
> > >Infocom in look and feel.
> First: What is this "Infocom in look an feel"? Isn't that an
> incredibly silly issue? Both systems let you redefine the look and
> feel don't they?
Yes, and on average, nobody does. That is, people do, but in different
directions.
I actually don't think there's an *Infocom* feel to either of them. But
there is a TADS feel and an Inform feel, which are noticeably different.
To me. I don't know if I can articulate the difference. It is not
unreasonable to prefer one over the other, as a player.
> What is it you can't do in TADS that someone would realistically want
> to do?
Realistically, people want to do everything. Honest.
I don't know the TADS parser the way I know Inform. But the only thing
hardwired in the Z-machine is breaking input up into a list of
space-delimited dictionary words.[*] I'm not saying that to praise Inform;
I want to point out that just about every part of the Inform library *has*
been changed in some game or another. That means that, realistically,
people have wanted to change everything after that first input parsing.
[* Yes, they've wanted to change that first parsing, too. Yes, it's
possible to modify or bypass that hardwired step, although it's a little
uglier because it's hardwired.]
> And design the game *without* knowing TADS or Inform first! Then you
> start noticing the gaps that one or the other language doesn't handle
> well (ie, maximum number of properties, lack of parser support, how
> hard it is to redesign the standard library to do things your way,
> etc).
I do really design my games before starting to think about
implementation. I do notice the things that Inform doesn't handle well.
Oh, believe me, I do.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Darin Johnson
fake...@anti-spam.address (Neil K.) writes:
> Pain in the arse, but there you go. However HTML-TADS understands
> ISO Latin 1, and hopefully non-HTML TADS interpreters can be made to
> understand whatever ISO Latin 1 codes are appropriate.
But I want to do an ISO Latin 3 game! (but I don't care for HTML, so
it's not a drawback :-)
--
Darin Johnson
da...@usa.net.delete_me
Alan Conroy
On Thu, 30 Apr 1998 14:46:58 -0500, "John E"
<johnDEL...@earthlink.net> wrote:
>Ok guys,
>I know this is a biggie.
>
>But if you could please give me a good reason to choose
>one over the other. I've been told that Inform has more of
>a 'Infocomish' feel. From what I've seen of TADS is looks
>a lot like C++. Is one easier to use? Would I lose any flexibility?
>Which is better for beginners? I know basic programming, Pascal, and some
>C.
>
>Post a response or please e-mail
>
>DELETE the word DELETE guys!!!
>
>johnDEL...@earthlink.net
>
>(of course ALAN looks good too ;> )
If you are familiar with BASIC and Pascal, you might want to consider
Adventure Builder which uses a language that some have said looks like
a cross between the two. You can get it from the archives or from
http://www.accessone.com/~conroy/ab.html
- Alan Conroy
The views expressed in this post are mine and not necessarily those of my spouse, employer, government, or God.
But then again...
HarryH
In article <354d9d1a.91128590@news>, knot...@yellowpine.com says...
>On Sat, 02 May 1998 00:31:08 GMT, Darin Johnson
><da...@usa.net.removethis> wrote:
>>start noticing the gaps that one or the other language doesn't handle
>>well (ie, maximum number of properties, lack of parser support, how
>>hard it is to redesign the standard library to do things your way,
>>etc).
>thought that can be quite limiting. Studying different tools, even if
>you never intend to use them for anything significant, can give you a
>new perspective on your favorite tools. I seldom use Perl or 80x86
>assembly language or Forth, but what I learned from all three has had
>a real beneficial impact on what I do with my tool of choice, C.
On the other hand, unless we are all Plotkin, we'll be forever pulling our
hair trying to do this simple but impossible task in our language of choice.
Shaping the program according to the limitations of the language should not
be considered stupidity, but efficiency.
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Mark J Musante
HarryH (har...@iu.net.idiotic.com.skip.idiotic.com) wrote:
> On the other hand, unless we are all Plotkin, we'll be forever pulling our
> hair trying to do this simple but impossible task in our language of choice.
Eh? I'm not sure whether to be insulted by this. Are you saying that zarf
is the only one in the universe who can program without pulling his hair out?
I guess it all depends on your definitiion of "this simple but impossible
task". I've read over, twice, the text of the message from which your
sentence above has been excerpted and, I have to admit, I have no idea what
you're talking about.
> Shaping the program according to the limitations of the language should not
> be considered stupidity, but efficiency.
I agree that the language you use dictates, to a degree, the design of your
program. But there's a certain sense of accomplishment to be gained when
pushing a language to its limits; when exploring the boundaries of its
abilities.
-=- Mark -=-
Darin Johnson
olo...@world.std.com (Mark J Musante) writes:
> Eh? I'm not sure whether to be insulted by this. Are you saying that zarf
> is the only one in the universe who can program without pulling his
> hair out?
I can do this too. Of course, these days, it's really hard to find a
good handful of hair on my head...
--
Darin Johnson
da...@usa.net.delete_me
Mark J. Tilford
>why its up to him, I've no idea)
That's simple. It's up to Zarf because he knows voodoo, and will use it
against anybody who releases a standard he doesn't approve of.
--
-----------------------
Mark Jeffrey Tilford
til...@cco.caltech.edu
Andrew Plotkin
Mark J. Tilford (til...@ralph.caltech.edu) wrote:
> On Fri, 01 May 1998 10:51:14 -0600, L. Ross Raszewski <rras...@hotmail.com> wrote:
> > (and if Zarf approves, though
> >why its up to him, I've no idea)
> That's simple. It's up to Zarf because he knows voodoo, and will use it
> against anybody who releases a standard he doesn't approve of.
This is not true.
Anybody who suggests otherwise... well, your medical insurance is up to
date, right?
Stephen Robert Norris
In article <slrn6kt4ra....@ralph.caltech.edu>,
til...@ralph.caltech.edu (Mark J. Tilford) intoned:
> On Fri, 01 May 1998 10:51:14 -0600, L. Ross Raszewski <rras...@hotmail.com> wrote:
>> (and if Zarf approves, though
>>why its up to him, I've no idea)
>
> That's simple. It's up to Zarf because he knows voodoo, and will use it
> against anybody who releases a standard he doesn't approve of.
Or against anyone who mentions it in an open forum, he does
Den of Iniquity
On 5 May 1998, Mark J. Tilford wrote:
>L. Ross Raszewski wrote:
>> (and if Zarf approves, though why its up to him, I've no idea)
>
>That's simple. It's up to Zarf because he knows voodoo, and will use it
>against anybody who releases a standard he doesn't approve of.
Oh, I thought it was because he's well experienced with Inform and the
working of the z-machine, is possibly only equalled by Graham in terms of
how much an Inform change will affect him as an author and because his
experience and opinion are widely respected. Shucks, there pops another
bubble-like illusion.
--
Den
Larry Smith
L. Ross Raszewski wrote:
> On the other hand, TADS is not constrained by the size limitiations of the
> Z-machine. (Though only a very few games have ever even approached the
> Z-machine's size limit, and if there's a need (and if Zarf approves, though
> why its up to him, I've no idea) Graham will add a new version of the
> z-machine with a higher limit)
I'd be interested in seeing a zmachine that could chain to new
z-code based scenarios, rather then one that just has a new memory
model. As if I could finish Zork I and then chain directly to the
start of Zork II, for example. It's not quite trivial - certain
objects will need to be transportable - but it should provide a
relatively easy extension.
I'd also like to see a callout opcode that would let me add my
own opcodes to the zmachine which would trigger extensions added
to the z-code interpreter with dynamic loading, much like TCL can
do.
These approaches would provide us with some interesting new
directions to explore. One of the things I'm kind of messing
around with right now is automated production of inform games
using table-driving input. This, coupled with the chaining
opcodes above, would allow the illusion of vastly larger and
more flexible games without requiring that much code support.
--
.-. .-. .---. .---. .-..-. |Politics is the art of looking for
| |__ / | \| |-< | |-< > / |trouble, finding it, misdiagnosing
`----'`-^-'`-'`-'`-'`-' `-' |it and then misapplying the wrong
My opinions only. |remedies. Groucho Marx
Eric O'Dell
On Mon, 18 May 1998 14:31:22 -0400, Larry Smith <l...@zk3.dec.com>
wrote:
>I'd be interested in seeing a zmachine that could chain to new
>z-code based scenarios, rather then one that just has a new memory
>model. As if I could finish Zork I and then chain directly to the
[...snip...]
>These approaches would provide us with some interesting new
>directions to explore. One of the things I'm kind of messing
>around with right now is automated production of inform games
>using table-driving input. This, coupled with the chaining
>opcodes above, would allow the illusion of vastly larger and
>more flexible games without requiring that much code support.
Maybe what we ought to be looking at, at least in the long run, is a
more powerful underlying virtual machine than either TADS or Inform
that could serve as a universal basis for future IF work. If designed
well, there's no reason why there couldn't be compilers for both
languages that output "x machine" code, just as there are compilers
for the Java virtual machine that compile from source languages other
than Java, like IBM's NetRexx.
--Eric
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
Philip Bartol
In article <356254ec.19026047@news>, er...@gadgetguru.com wrote:
>Maybe what we ought to be looking at, at least in the long run, is a
>more powerful underlying virtual machine than either TADS or Inform
>that could serve as a universal basis for future IF work. If designed
>well, there's no reason why there couldn't be compilers for both
>languages that output "x machine" code, just as there are compilers
>for the Java virtual machine that compile from source languages other
>than Java, like IBM's NetRexx.
I hate to be a party pooper, but isn't that one of those, "been tried, doesn't
work" ideas? There must be some reason that people keep using Inform & TADS,
there are other programs out there, I even downloaded one after reading a
review of the system and the author (and found it didn't run at all for me,
and made even less sence).
If there is a Virtual machine the code will have to be made accessable to all
systems the 1st time, hacking out a program in Visual BASIC and then expecting
people to port it to DOS, Mac, etc. isn't going to happen, Inform runs on a
bunch of systems now, and the code is avalable (and portable enough) to be
transfered to other systems... the DOS compiler (which I still use, even
though I run Win95) has virtually no interface, it's a command-line thing
(I've not seen the Win95 version, but I'm sure it's had any interface loaded
onto the existing code).
My point is, that Inform (and I assume TADS) run on multiple machines (I hope
reliably) so they have as big an audience as can be gotten, any new machine
would have to work in the same way.
PHIL
Neil K.
(Kent Tessman) wrote:
> In article <6jusa3$fnk$1...@gte1.gte.net>, phi...@gte.net (Philip Bartol) wrote:
> >My point is, that Inform (and I assume TADS) run on multiple machines
(I hope
> >reliably) so they have as big an audience as can be gotten, any new machine
> >would have to work in the same way.
>
> On the other hand, I think, say, a Mac port is something that's way, way
> overrated.
Why? There is a much higher percentage of Mac users playing IF (judging
by the people who hang out on raif and the MUD) than the general
population. I think the lack of a Mac port for Hugo is part of the reason
there are relatively few games written for it.
- Neil K.
Eric O'Dell
On Wed, 20 May 1998 15:28:15 GMT, phi...@gte.net (Philip Bartol)
wrote:
>I hate to be a party pooper, but isn't that one of those, "been tried, doesn't
>work" ideas? There must be some reason that people keep using Inform & TADS,
>there are other programs out there, I even downloaded one after reading a
>review of the system and the author (and found it didn't run at all for me,
>and made even less sence).
The reason people keep using Inform and TADS is because both offer
powerful and relatively easy-to-use languages, not because of their
underlying virtual machines. People keep using C and C++ for much the
same reasons without very much consideration as to whether their
program is running on an 80x86 machine or an Alpha.
>If there is a Virtual machine the code will have to be made accessable to all
>systems the 1st time, hacking out a program in Visual BASIC and then expecting
>people to port it to DOS, Mac, etc. isn't going to happen,
I do not "hack out" programs in Visual Basic. <snif> :)
The virtual machine would probably be coded in C, just like the TADS
and Inform VMs. The only system dependencies would probably be in the
display code, which in IF games is not especially sophisticated or
complex anyway. If pains were taken to code everything else in
portable ANSI C, ports to other systems would be almost easy.
>My point is, that Inform (and I assume TADS) run on multiple machines (I hope
>reliably) so they have as big an audience as can be gotten, any new machine
>would have to work in the same way.
I think you're confusing the VM with the language. A virtual machine
need be no more language-dependent than a hardware system, which is
what it's emulating anyway. Most modern compilers for general purpose
programming languages like C/C++, Pascal, etc., are designed in a
modular fashion so that multiple target-specific code generators can
be wedded to a single front end, which is where the actual language
parser is located, and vice versa --- witness the GNU C/C++ compiler,
whose many versions can not only generate executables for a
bewildering array of systems, but can also swap front-ends to be able
to handle source code written in GNU's own C/C++ dialect, Ada, and
Fortran.
A generic IF VM could be the target of new versions of both the Inform
and TADS compilers, just as my humble PC is targeted by compilers for
C/C++, Pascal, Forth, Fortran, COBOL, and dozens of other languages.
Neil K.
tes...@remove-to-reply.interlog.com (Kent Tessman) wrote:
> > Why? There is a much higher percentage of Mac users playing IF (judging
> >by the people who hang out on raif and the MUD) than the general
> >population. I think the lack of a Mac port for Hugo is part of the reason
> >there are relatively few games written for it.
>
> Aieee! 'Twas a joke! Although as was pointed out to me, it might've helped
> said joke's cause if it were actually funny. :)
Oops. Well, sorry... I must admit that it didn't come across to me as a
joke but rather a somewhat odd remark.
Still, the difficulty in finding Mac programmers to port Hugo, HTML TADS
and z6-compliant Zmachine terps does give me pause. It's interesting that
there seem a fair number of Mac types here, but with a few notable
exceptions most of us appear to be more knowledgeable and competent users
(I'm trying to avoid that rather 80s term "power users") than actual
hackers capable of building a decent application. Maybe we sublimate our
programming desires with scripting or IF authoring rather than hacking. Or
something.
Andrew Plotkin
Neil K. (fake...@anti-spam.address) wrote:
> Still, the difficulty in finding Mac programmers to port Hugo, HTML TADS
> and z6-compliant Zmachine terps does give me pause. It's interesting that
> there seem a fair number of Mac types here, but with a few notable
> exceptions most of us appear to be more knowledgeable and competent users
> (I'm trying to avoid that rather 80s term "power users") than actual
> hackers capable of building a decent application.
Not to jerk my knee too badly, but I'm sure this is true on every
platform. How many Win95 users are there around here, and how many of
them have written Win95 interpreters for some IF system?
Naturally, this is another formulation of the basic problem I've been
trying to solve for months.
Steven Posey
On Wed, 20 May 1998 04:02:36 GMT, er...@gadgetguru.com (Eric O'Dell) wrote:
>On Mon, 18 May 1998 14:31:22 -0400, Larry Smith <l...@zk3.dec.com>
>wrote:
>
>>I'd be interested in seeing a zmachine that could chain to new
>>z-code based scenarios, rather then one that just has a new memory
>>model. As if I could finish Zork I and then chain directly to the
>
>[...snip...]
What I would like to see is a disk-based model that didn't rely on conventional memory constrainsts.
You know, something that would maintain the "world" variables (inventory, location, score, etc.) but
use disk pointers for the descriptions and such. That way, the game could be as large as available
hard drive space, but only take up a small portion of the computer's memory.
>
>Maybe what we ought to be looking at, at least in the long run, is a
>more powerful underlying virtual machine than either TADS or Inform
>that could serve as a universal basis for future IF work. If designed
>well, there's no reason why there couldn't be compilers for both
>languages that output "x machine" code, just as there are compilers
>for the Java virtual machine that compile from source languages other
>than Java, like IBM's NetRexx.
I do not have TADS, so I can't say why people use it, but I use Inform because it generates code
that is compatible with Infocom z-machine code. I find a personal satisfaction in creating
something within the same environment as the IF games that I played as a teenager. It's a big
thrill for me to play HHGG in Frotz and then switch over to play a game I wrote. Seeing my writing
side by side with Infocom stories is a personal triumph. If someone could write a translator that
would take z-code and convert it to "x-code", I would probably switch to an "x-machine" compiler.
Until then, I'll stick with the z-machine.
Steven
Jonadab
> I'd be interested in seeing a zmachine that could chain to new
> z-code based scenarios, rather then one that just has a new memory
> model. As if I could finish Zork I and then chain directly to the
> objects will need to be transportable - but it should provide a
> relatively easy extension.
>
> I'd also like to see a callout opcode that would let me add my
> own opcodes to the zmachine which would trigger extensions added
> to the z-code interpreter with dynamic loading, much like TCL can
> do.
>
> directions to explore. One of the things I'm kind of messing
> around with right now is automated production of inform games
> using table-driving input. This, coupled with the chaining
> opcodes above, would allow the illusion of vastly larger and
> more flexible games without requiring that much code support.
>
That would also enable someone to create an actual operating system for the
z-machine (at least theoretically -- perhaps??) that could allow one to
exit one game and load another without leaving the z-machine, for what it
would be worth. In practice, I don't suppose it matters, but it would be
interesting, anyway. Task swapping might not be possible, though; I don't
know, and I'm almost sure multitasking is out of the question, right?
Just a thought sparked off by the idea of chaining.
Branko Collin
>>more powerful underlying virtual machine than either TADS or Inform
>>that could serve as a universal basis for future IF work. If designed
>>well, there's no reason why there couldn't be compilers for both
>>languages that output "x machine" code, just as there are compilers
>>for the Java virtual machine that compile from source languages other
>>than Java, like IBM's NetRexx.
>
>work" ideas? There must be some reason that people keep using Inform & TADS,
>there are other programs out there, I even downloaded one after reading a
>review of the system and the author (and found it didn't run at all for me,
>and made even less sence).
I think it's the same type of problem as with the competition; nobody
wants to do the hard work, but everyone wants to be a critic.
So every week threads pop up where people go:
"Why don't we have a rule in the competition that ..."
"Why can't we change Inform in such a way that ..."
The answer being of course that it's not their product to tamper with
in the first place.
If you want a competition with rules X,Y and Z, organise one.
If you want a compiler/interpreter that does A,B and C, build one.
--
branko collin
col...@xs4all.nl
help me pick my glasses: http://www.xs4all.nl/~collin/bril/
Larry Smith
Eric O'Dell wrote:
> On Mon, 18 May 1998 14:31:22 -0400, Larry Smith <l...@zk3.dec.com>
> wrote:
> >I'd be interested in seeing a zmachine that could chain to new
> >z-code based scenarios, rather then one that just has a new memory
> >model.
> >These approaches would provide us with some interesting new
> >directions to explore. One of the things I'm kind of messing
> >around with right now is automated production of inform games
> Maybe what we ought to be looking at, at least in the long run, is a
> more powerful underlying virtual machine than either TADS or Inform
> that could serve as a universal basis for future IF work.
I'd prefer not to take this approach just yet.
The reasons are fairly simple: I do not believe we have
really reached the limits of the current z-machine arch-
itecture - and until we do, I don't think we can do very
much toward defining a fundamentally different _and_bet-
ter_ one. Linking games, such as outlined above, is
merely a convenience for building a modular game. I
could use it in a Star Trek style game, for example,
by having one z-program for the Enterprise, another
for Voyager, another for Deepspace 9, and so on. This
is an incremental improvement that takes advantage of
naturally modular material. One could define a new,
32-bit z-machine and allow millions of rooms - but
why bother when much the same effect can be had more
cheaply?
MUDs of various flavors already use quite sophisticated
scripting languages that in many respects form a more
"powerful" architecture - certainly with few or none
of the architectural limits of the z-machine. But
they do not seem to be able to produce games that are
demonstrably better. Larger, yes. But not really
better, aside from multi-user features. These games
seem scarcely more than tiny improvements over dungeon
and adventure.
Any why leave behind the existing work? Zork and the
others are classics. I'd much rather keep them up to
date and runnable with current systems. I think a per-
iod of minor improvements in several directions would
give us a better idea of where we want to go in the
future. A user-expandable z-machine instruction set
would let us experiment along these lines without
losing our investment in current technology. And
let's face it: current technology IS quite good.
An expandable z-machine could be done fairly easily
by building a "plugin" interface for zip and frotz.
Once we have had a period of experimenting, it would
be worthwhile to evaluate what people had felt they
had cause to add to the z-machine and use it as a
guide for a next-generation system.
Jonadab
Andrew Plotkin <erky...@netcom.com> wrote in article
<erkyrathE...@netcom.com>...
> Neil K. (fake...@anti-spam.address) wrote:
> > there seem a fair number of Mac types here, but with a few notable
> > exceptions most of us appear to be more knowledgeable and competent
users
> > (I'm trying to avoid that rather 80s term "power users") than actual
> > hackers capable of building a decent application.
>
> Not to jerk my knee too badly, but I'm sure this is true on every
> platform. How many Win95 users are there around here, and how many of
> them have written Win95 interpreters for some IF system?
But aren't GUI-based systems user-oriented to start?
DOS used to be, but a lot of the users have upgraded to Windoze, so DOS (of
itself) is more hacker-oriented now than it was.
Of course, OSes like Unix are very hacker-oriented. Aren't most of the
people who use, for example, Linux, hackers? I don't claim to be an expert
on that, but that was my impression.
--
From 501 uses for peanut butter:
7. Make sure you have some stuck in your
fingernails whenever you go on a blind date.
My Current Quote: "Say, look who has email again!"
"I" /\ \I /\ I\ /\ I) /\ I) I) 1 /_ II "I" \I [" "I"
\I \/ I\ II I/ II I) \a I) I\ 1 \/ TT I o I\ [_ I
Jonadab
Philip Bartol <phi...@gte.net> wrote in article
> ... hacking out a program in Visual BASIC and then expecting
> people to port it to DOS, Mac, etc. isn't going to happen,
> Inform runs on a bunch of systems now, and the code is avalable
> (and portable enough) to be transfered to other systems...
> My point is, that Inform (and I assume TADS) run on multiple
> machines (I hope reliably) so they have as big an audience as
> can be gotten, any new machine
> would have to work in the same way.
>
> PHIL
The ultimate in portability would be (as far as I know) ANSI C. Of course,
then you either have to compile separate binaries for every platform or
distribute as source, because there's no virtual machine. I think Inform
(for example) is quite portable enough for our purposes.
--
From 501 uses for peanut butter:
357. Use it for mulch in your strawberry patch.
Invading birds will get stuck.
My Current Quote:
"How do you represent 6 octaves on a traditional staff?"
Paul A Krueger
Larry Smith wrote in message <35607E...@zk3.dec.com>...
>L. Ross Raszewski wrote:
>I'd be interested in seeing a zmachine that could chain to new
>z-code based scenarios, rather then one that just has a new memory
>model. As if I could finish Zork I and then chain directly to the
>start of Zork II, for example. It's not quite trivial - certain
>objects will need to be transportable - but it should provide a
>relatively easy extension
It would only be possible if you created a set of games where the next game
knew exactly what the objects where and what they where for. Example : Zork2
doesn't know what a pump is, and even if you got it to recognize the word,
and better yet let you have one, what would you *do* with it? Zork2 only
knows the purpose of the objects that were programmed in, and doesn't even
have any appropriate responses for using it. Even if you made a game that
could handle everything from the previous game, you'd have to explain why
you didn't just write it as one longer game instead. Or better yet, wait for
the Inform version of Dungeon to get finished.
Weird Beard
weird...@prodigy.net
John Elliott
"Paul A Krueger" <WEIRD...@prodigy.net> wrote:
>
>Larry Smith wrote in message <35607E...@zk3.dec.com>...
>>L. Ross Raszewski wrote:
>>I'd be interested in seeing a zmachine that could chain to new
>>z-code based scenarios
>
>knew exactly what the objects where and what they where for.
Games for tape-based micros did this, because it was about the only way
of getting bigger games than would fit into available memory. At the end of
part 1, a SAVE opcode would be executed; the user would then load Part 2,
which would start with a LOAD opcode. The sequence wasn't always linear;
some games allowed you to move back and forth between multiple parts using
this system.
This was easier with the Quill (and its successor, PAW) than with Z-code,
because all games had the same RAM size and savefile format - so part 2 could
be sure of reading the part 1 savefile correctly. Even so, it required some
care in allocating ranges of location numbers.
>Even if you made a game that
>could handle everything from the previous game, you'd have to explain why
>you didn't just write it as one longer game instead.
With the virtual memory system in the Z-machine, there's not much point.
And the major problem is sharing the dynamic RAM between part 1 and part 2;
the author would have to ensure that all the tables were the same size in
both games, or the interpreter would have to do a lot of work moving things
about.
On the other hand, the original author might have meant chaining without
preserving the state of the previous program, which makes life a lot easier.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Eric O'Dell
On 24 May 1998 09:20:48 GMT, "Jonadab" <jon...@bright.net> wrote:
>The ultimate in portability would be (as far as I know) ANSI C. Of course,
>then you either have to compile separate binaries for every platform or
>distribute as source, because there's no virtual machine. I think Inform
>(for example) is quite portable enough for our purposes.
I've more than once considered building an IF development system that
compiled to ANSI C, but there's a huge portability hurdle in such a
venture, at least if you want to be able to support games larger than
memory --- there's no cross-platform way of handling shared libraries.
DOS doesn't even have such an animal, though it is probably easier to
hack it in assembly language under DOS than elsewhere. Windows
apparently doesn't support loading individual routines from DLLs
without loading the whole damn DLL.
Interpreted bytecode sidesteps the whole issue, of course, since you
can quite casually load individual records from a game (read:
database) file without giving the OS a second thought. Which, I
suppose, is why the TADS and Inform runtimes are bytecode interpreters
and not program loaders.
I feel pretty confident that I could code a virtual machine without
losing too much hair in the process, but the compiler is probably
beyond me unless you'd like a Forth-like postfix language. I've been
staring at Holub's _Compiler Design in C_ for some time now, and aside
from NFA <-> DFA conversion and symbol table management, the only
thing I've learned is that compiler design is not a good independent
study project for people with day jobs.
And yes, I am threatening to write the runtime system if someone else
feels up to writing the compiler.
okbl...@usa.net
In article <3569cd32.75558438@news>,
er...@gadgetguru.com wrote:
>
> I've more than once considered building an IF development system that
> compiled to ANSI C, but there's a huge portability hurdle in such a
> venture, at least if you want to be able to support games larger than
> memory --- there's no cross-platform way of handling shared libraries.
> DOS doesn't even have such an animal, though it is probably easier to
> hack it in assembly language under DOS than elsewhere. Windows
> apparently doesn't support loading individual routines from DLLs
> without loading the whole damn DLL.
>
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Andrew Plotkin
Eric O'Dell (er...@gadgetguru.com) wrote:
> Which I have considered, as mentioned elsewhere, but I always run up
> against the question: Who would want to write a text adventure in
> Forth? I mean, *I'd* do it, but then I do lots of things in my spare
> time that draw odd looks from strangers.
I should write one in PostScript, just to show all yinz.
Eric O'Dell
On Tue, 26 May 1998 17:55:21 GMT, okbl...@usa.net wrote:
>You could do it in PL/I, if you could find/afford the compiler.
Finding a PL/I compiler is easy; it's the price that will get you.
Provided, of course, that you get past the fact that PL/I is one of
those languages about which people say, "Ah, PL/I, now there's an ---
uh --- *interesting* language." The postfix stack languages fall into
the same category, though they at least have the advantage of being
easy to write compilers for...
Which I have considered, as mentioned elsewhere, but I always run up
against the question: Who would want to write a text adventure in
Forth? I mean, *I'd* do it, but then I do lots of things in my spare
time that draw odd looks from strangers.
After sketching out the details during lunch today, I remain confident
that I can code a superior virtual machine/runtime interpreter and a
macro assembler for the same, but as far as compilers more
sophisticated than some Forth dialect go, I defer to someone who
doesn't view lex and yacc with superstitious dread.
Larry Smith
Paul A Krueger wrote:
> Larry Smith wrote in message <35607E...@zk3.dec.com>...
> >L. Ross Raszewski wrote:
> >I'd be interested in seeing a zmachine that could chain to new
> >z-code based scenarios, rather then one that just has a new memory
> >model. As if I could finish Zork I and then chain directly to the
> >start of Zork II, for example. It's not quite trivial - certain
> >objects will need to be transportable - but it should provide a
> >relatively easy extension
>
> It would only be possible if you created a set of games where the next game
> knew exactly what the objects where and what they where for.
Ideally, yes. I picked the Zork example to illustrate one
well-known example, not because I expected to actually add
the feature to it (Zork does not have the new opcode anyway).
Of course, once Disinform is a little further along, who
knows? =)
> Even if you made a game that
> could handle everything from the previous game, you'd have to explain why
> you didn't just write it as one longer game instead.
Not really. There are a number of reasons why I think
this approach is a good idea, only some of which relate
directly to chaining actual games.
1. Because longer games take longer to get released. It would
be nice to release a smaller game, get feedback and ideas for
the next game and then release that, and so on. Players yet
lacking the next game would simply save their characters until
the next game came out.
2. This is not just a way to chain games, it's a way to org-
anize and present games that are potentially much larger and
more complex than the limits of the current z-machine without
abandoning the z-machine, inform, or current technology.
3. It provides a way for z-code to launch other z-code
programs, which would allow us to write more sophisticated
z-code program suites. z-code modules could be compiled
from Inform, generated by tables or generic algorithms,
etc. If the idea is useful, more opcodes to help slice
and dice z-code libraries would be able to help us do
things like pick up objects and carry them from game to
game. Again, without losing our investment in the z-machine.
If these ideas began to warp the z-machine into something
totally weird, then it would be time to look at the possibility
of designing a new adventure writing system, or at least a new
z-machine architecture. But I think we have a lot of headroom
now, and this bit of effort would get us even more.
> Or better yet, wait for
> the Inform version of Dungeon to get finished.
I hadn't heard of anyone working on this. Cool! Can you
provide some details? This is a project sitting on my to-do
list, I'd love to take it off... =)
Dan Shiovitz
In article <356ba9f9.27706574@news>, Eric O'Dell <er...@gadgetguru.com> wrote:
>On Tue, 26 May 1998 17:55:21 GMT, okbl...@usa.net wrote:
>After sketching out the details during lunch today, I remain confident
>that I can code a superior virtual machine/runtime interpreter and a
>macro assembler for the same, but as far as compilers more
>sophisticated than some Forth dialect go, I defer to someone who
>doesn't view lex and yacc with superstitious dread.
Lex and yacc are really not that big a deal; except for printing error
messages, they're definitely easier & cleaner than coding the thing by
hand. If they scare you, though, you may want to look into ANTLR
(www.antlr.org), a top-down instead of bottom-up parser.
>--Eric
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)
Eric O'Dell
On Wed, 27 May 1998 06:17:49 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:
>> Which I have considered, as mentioned elsewhere, but I always run up
>> against the question: Who would want to write a text adventure in
>> Forth? I mean, *I'd* do it, but then I do lots of things in my spare
>> time that draw odd looks from strangers.
>
>I should write one in PostScript, just to show all yinz.
Heh. If you did, I believe that would displace whatshisname's
retargetable assembler written in AWK as the all time most
inappropriate use of a language. Of course, if you really want to dig
through that barrel, you could always implement the UI using Display
PostScript.
Of course, now that I've had time to think about it, maybe it wouldn't
be too hard to write a compiler for a C-like adventure language. After
all, most of the things that make C hard to parse are not necessarily
issues when it comes to a special-purpose dialect of the language. For
one, designing the VM along with the compiler means that you can
arbitrarily add opcodes to make code generation easier, rather than
having to adapt to a pre-existing (and possibly suboptimal) set of
opcodes. And many of the more difficult constructs of the language ---
bit fields and unions --- are dispensible, and much of the remainder
can be simplified --- fewer types, for example. The only thing I have
a bit of trouble with is operator precedence in complex expressions,
and between Holub and the Bison manual, I should be able to figure it
out.
One thing I was thinking about today is that there is already a
substantial body of research on IF-like parsing out there. There's an
entire sub-branch of natural language processing research revolving
around what are called "controlled languages", i.e., rigidly defined
subsets of natural languages designed to be machine readable. IF
operates under similar constraints: for each game, there are a finite
(and usually rather small) number of words that the parser understands
and, for that matter, an even smaller number of syntactical
constructs. Perhaps an examination of research on the subject might
lead to some advances in IF parsers and their underlying object
models. Or maybe even advances in NPC interaction.
L. Ross Raszewski
> > >L. Ross Raszewski wrote:
> > >I'd be interested in seeing a zmachine that could chain to new
> > >z-code based scenarios, rather then one that just has a new memory
> > >model. As if I could finish Zork I and then chain directly to the
> > >start of Zork II, for example. It's not quite trivial - certain
> > >objects will need to be transportable - but it should provide a
> > >relatively easy extension
> >
Look, I didn't write this, so what is my name doing on it?
Allen Garvin
In article <01bd862e$b6c19740$0b118fd1@jonadab>,
Jonadab <jon...@bright.net> wrote:
Of course, OSes like Unix are very hacker-oriented. Aren't most of
the people who use, for example, Linux, hackers? I don't claim to
be an expert on that, but that was my impression.
A couple or three years ago when Linux was young, that was true. But now it's
sort of becoming a cool thing that everyone wants to run, even by people that
have no knowledge of unix. You can sometimes identify these people by the way
they run around cursing Bill Gates, and asking questions like "how does grep
work?". Still, the percentage of people who program probably runs much higher
than on other systems.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
David Rush
er...@gadgetguru.com (Eric O'Dell) writes:
> erky...@netcom.com (Andrew Plotkin) wrote:
> >> Which I have considered, as mentioned elsewhere, but I always run up
> >> against the question: Who would want to write a text adventure in
> >> Forth? I mean, *I'd* do it, but then I do lots of things in my spare
> >> time that draw odd looks from strangers.
Heh. Me too...
> >I should write one in PostScript, just to show all yinz.
> Heh. If you did, [...] the all time most inappropriate use of a
> language. Of course, if you really want to dig through that barrel,
> you could always implement the UI using Display PostScript.
Well, I dunno about that. PostScript is, IMNSHO, a *great* language
buried under the weight of a display library. Dictionaries are as
close to *the* most fundamental non-atomic data structure as can be
conceived, and postfix is only weird to aristocrats (who believe in
precedence hierarchies :)
> One thing I was thinking about today is that there is already a
> substantial body of research on IF-like parsing out there.
Yep, and I've been following it as midnight engineering for
years. Rebuilding the parser and its integration with the run-time
libraries is the main reason why I haven't written an IF language for
the last 10 years. (The one I did build was an overblown threaded
interp, by the way, postfix and all).
> entire sub-branch of natural language processing research revolving
> around what are called "controlled languages", i.e., rigidly defined
> subsets of natural languages designed to be machine readable. IF
> operates under similar constraints [...] an examination of research
> on the subject might lead to some advances in IF parsers and their
> underlying object models. Or maybe even advances in NPC interaction.
My current motivation for building an IF engine is because the
Z-machine is just *so* primitive. I'd really like to see something
rather more modern to work with, and I think that an engine based on
fuzzy inference might open up a *lot* of possibilities for
improvements in NPCs.
Care to brainstorm a bit? I've done a fair bit of both compiler and VM
work in the past, but I'm a bit tight for time right now. (Translate
as: I don't think I could finish such a project by myself in finite
time).
david rush
--
>>Foof!<< You're at Y2.
A hollow voice says: "Plugh"
Eric O'Dell
On 28 May 1998 12:54:44 -0400, David Rush <ku...@intercenter.net>
wrote:
>Well, I dunno about that. PostScript is, IMNSHO, a *great* language
>buried under the weight of a display library. Dictionaries are as
>close to *the* most fundamental non-atomic data structure as can be
>conceived, and postfix is only weird to aristocrats (who believe in
>precedence hierarchies :)
I can't actually speak for PostScript, my experience with it has been
limited to watching Acrobat fail to parse it correctly, but I confess
to finding a certain charm in postfix languages. Complex expressions
are, however, a lot less readable in postfix notation than they are in
infix notation, so I'm not sure a Forthish language would go over very
well in IF, as a lot of IF authors don't do any programming outside of
IF.
Of course, one of the things I would like to see is a single VM with
several compilers for different languages, especially if the calling
conventions were compatible, which would hopefully quell a lot of the
pointless language disputes.
>My current motivation for building an IF engine is because the
>Z-machine is just *so* primitive. I'd really like to see something
>rather more modern to work with, and I think that an engine based on
>fuzzy inference might open up a *lot* of possibilities for
>improvements in NPCs.
Indeed it might.
>Care to brainstorm a bit? I've done a fair bit of both compiler and VM
>work in the past, but I'm a bit tight for time right now. (Translate
>as: I don't think I could finish such a project by myself in finite
>time).
That would be great, with the caveat that I won't have much spare time
myself until around the end of summer.
BTW, per the speculation on controlled languages, I just posted copies
of three papers I found from a conference on controlled language
applications on the new Adventure Blaster page at:
http://members.home.net:80/eodell/if.html
Andrew Plotkin
L. Ross Raszewski (rras...@hotmail.com) wrote:
> > > >L. Ross Raszewski wrote:
> > > >I'd be interested in seeing a zmachine that could chain to new
> > > >z-code based scenarios, rather then one that just has a new memory
> > > >model. As if I could finish Zork I and then chain directly to the
> > > >start of Zork II, for example. It's not quite trivial - certain
> > > >objects will need to be transportable - but it should provide a
> > > >relatively easy extension
>
> Look, I didn't write this, so what is my name doing on it?
If you look at the indentation, it's obvious: someone was replying to
an N'th reply to your post, and snipped out the N-nested quote, but only
the (N-1)-nested attribution.
Very common accident. Usually not worth posting about.
Paul A Krueger
Actually, "L. Ross Raszewski (rras...@hotmail.com) wrote:" was written by
the original post, but I didn't catch it while I was snipping dialouge. We
apologize for the inconvenience. <1>
Weird Beard
weird...@prodigy.net
<1> God's final message to his creatures.
Larry Smith
Eric O'Dell wrote:
> Which I have considered, as mentioned elsewhere, but I always run up
> against the question: Who would want to write a text adventure in
> Forth? I mean, *I'd* do it, but then I do lots of things in my spare
> time that draw odd looks from strangers.
"I LIKE him. He's SILLY..." - Tweety Bird =)
My favorite bumper sticker: FORTH LOVE IF HONK THEN
> After sketching out the details during lunch today, I remain confident
> that I can code a superior virtual machine/runtime interpreter and a
> macro assembler for the same, but as far as compilers more
> sophisticated than some Forth dialect go, I defer to someone who
> doesn't view lex and yacc with superstitious dread.
Actually, I _do_ view lex and yacc with superstitious dread
- but writing a decent compiler without them isn't at all
difficult. Pick up a copy of Niklaus Wirth's newest book
http://www.amazon.com/exec/obidos/ASIN/0201403536/o/002-3064004-8328805
He'll show you how to write a simple infix notation compiler
that will dovetail nicely with your Forth background.
Stephen Robert Norris
In article <6kkqjl$n4f$1...@nnrp1.dejanews.com>,
L. Ross Raszewski <rras...@hotmail.com> intoned:
>
>
>> > >L. Ross Raszewski wrote:
>> > >I'd be interested in seeing a zmachine that could chain to new
>> > >z-code based scenarios, rather then one that just has a new memory
>> > >model. As if I could finish Zork I and then chain directly to the
>> > >start of Zork II, for example. It's not quite trivial - certain
>> > >objects will need to be transportable - but it should provide a
>> > >relatively easy extension
>> >
>
>
> Look, I didn't write this, so what is my name doing on it?
It doesn't say you did - by normal quoting conventions, you wrote
"", and some anonymous person wrote the rest (and someone trimmed the
attribution - given that the person who quoted them was presumably you,
probably you!).
It is misleading, though.
Stephen
Larry Smith
L. Ross Raszewski wrote:
> > > >L. Ross Raszewski wrote:
> > > >I'd be interested in seeing a zmachine that could chain to new
> > > >z-code based scenarios, rather then one that just has a new memory
> > > >model. As if I could finish Zork I and then chain directly to the
> > > >start of Zork II, for example. It's not quite trivial - certain
> > > >objects will need to be transportable - but it should provide a
> > > >relatively easy extension
> Look, I didn't write this, so what is my name doing on it?
I wrote it. It looks like someone tried to trim the attributions
and simply cut out the lines with fewer than four indents - for-
getting that the actual author of the forth indent is marked with
just three. Just a reminder to double-check attributions, folks!