My thoughts on Inform 7
Eric
sense to me, because it's clearly not. The documentation alone is designed
for someone that's got the conventions of IF down and it's also designed
like a stream of thought. I also keep hearing everyone argue about this
'metaphor' about how Inform is like writing a book. But there's nothing much
in the documentation that actually tries to draw this analogy. There's
nothing that really makes you feel this 'metaphor' is being used. So I'm
curious why everyone keeps talking about it? Does the documentation ever say
something like 'This is similar to how you might write a novel ......'
I'm finding that no matter what gloss you put over it, you're still stuck
with the z-machine and its limits. If there was ever an underlying system
that wasn't devoted to the beginner, this is it. I think Inform 7 would have
been better breaking with its past and creating a new VM, something more
powerful like T3. The benefit is all the support already available for it I
suppose. But if you're targeting beginners it's highly unlikely many of them
are setting there on many of the configurations that have been ported to
with Inform. I'm guessing you're mainly going to be targeting Mac and Win
users.
Khelwood
> I'm finding that no matter what gloss you put over it, you're still stuck
> with the z-machine and its limits. If there was ever an underlying system
> that wasn't devoted to the beginner, this is it. I think Inform 7 would have
> been better breaking with its past and creating a new VM, something more
> powerful like T3.
You're not stuck with the Z-machine or its limits. You can compile to
Glulx instead.
Eric
"Khelwood" <Khel...@gmail.com> wrote in message
news:1171028923....@v45g2000cwv.googlegroups.com...
Yeah, and that's even more convoluted than the z-machine in some ways. Isn't
it? I mean, yeah I can compile to it and remove some limits that the
z-machine imposes. But what's glulx offer that's actually better in terms of
designing a game? Does it change how you handle NPCs? Does it make it easier
to override the z-machine when it won't do what you want it to?
Khelwood
> "Khelwood" <Khelw...@gmail.com> wrote in message
I would have thought that the VM specifications were of little
relevance to handling NPCs. The NPC design features of TADS 3 come out
of its library, not its virtual machine.
And "override the Z-machine"? If you're compiling to Glulx then you're
not using the Z-machine, so I don't know what you mean by overriding
it.
Eric
But the constructions you're eventually allowed to create in the language
have to be translated into forms that the VM can understand and if the VM is
limited in the kinds of constructions it can understand, doesn't that mean
it can constrain how things like NPCs are created? Or what can be done with
the data structures that allow NPCs?
mikegentry
> I keep hearing that Inform 7 is designed for beginners and this doesn't make
> sense to me, because it's clearly not.
Actually, I think part of the problem is that a lot of people
(possibly including the authors of the documentation) are conflating
"beginners" with "non-programmers".
Khelwood
Nope. If someone were to write the libraries you could do much the
same thing in Inform.
Jeff Nyman
>I keep hearing that Inform 7 is designed for beginners and this doesn't
>make sense to me, because it's clearly not.
Of course it's not. Inform 7 is a programming language. No programming
language is *designed* for "beginners" necessarily -- where you have to
define what "beginner" means. That said, certain programming languages are
more amenable to people with little background in programming (whom you can
refer to as "beginners," I suppose) but even that is really up to the person
and can't be stated with any degree of assurance.
I will say this: languages like Inform 7, that try to put a veneer over the
programming aspects, can often be a bit more difficult for the true beginner
(meaning, again, one who lacks any sort of programming background) because
at those inevitable times when you *do* have to think like a programmer,
such a language has done nothing to prepare you for that. So sometimes you
get a bit of a cognitive disconnect. Some people can get over this
relatively easy, others not so much. Experience is usually what mediates
this. That's the case with any language.
> The documentation alone is designed for someone that's got the conventions
> of IF down and it's also designed like a stream of thought.
I'm not sure about the "stream of thought," per se, implying as it does
little structure.
Personally, when I read the I7 documentation I feel a bit like I'm listening
to someone lecture me about a system they know really, really well, and I'm
just trying to catch up and try to draw a picture based on the little
snippets I'm given. There's a lot there but I don't feel any of it will be
very cohesive until I have the whole picture. But the whole picture is what
I'm trying to get!
I've learned more by just taking source code, plugging it into the IDE, and
then checking out the Index tab and just searching around. This issue has
been referred to, however, in another thread about future Inform 7
developments. This is also something that the community (i.e., us) can help
with, as we can help write tutorials or things of that nature. My reluctance
to do so is that Inform 7 is still so much in flux, it would be a constant
update job for the time being.
Personal aside: I'm not a fan of the formal style, where everything is a
"we." User-friendly documentation is usually more personalized than that and
treats the reader as if you were having a friendly conversation. That's a
subjective opinion, of course, and doesn't speak to the content of what's
being given; just its presentation. (I should note a lot of TADS 3
documentation and source comments are written in this same format.)
> I also keep hearing everyone argue about this 'metaphor' about how Inform
> is like writing a book. But there's nothing much in the documentation that
> actually tries to draw this analogy. There's nothing that really makes you
> feel this 'metaphor' is being used. So I'm curious why everyone keeps
> talking about it?
This has been discussed quite a bit. I'm not sure how fruitful of a
discussion it is at this point. Clearly the metaphor is just this background
thing that no one, I think, is taking terribly seriously, at least in terms
of it guiding how they write interactive fiction in Inform 7. Personally,
I've come to believe (after discussions) that this is a distraction topic
from the substance of Inform 7 itself.
> Does the documentation ever say something like 'This is similar to how you
> might write a novel ......'
No, because most of what you're doing in Inform 7 is *not* how you would
write a novel (or a short story or most other forms of conventional
fiction). A lot of what you do to write a novel actually comes in before you
start writing: you plan out your characters, your setting, the narrative
that's going to pace the action in your story, etc. You can do all that with
a work of text-based interactive fiction but that's before you even start
writing the game. So Inform 7 doesn't come into play at that point. When
you're writing a conventional novel (short story, etc., etc.), you're not
phrasing things in terms of tables and rules and conditions and definitions
nor are you necessarily constraining your natural language nor are you
considering game mechanics.
> I'm finding that no matter what gloss you put over it, you're still stuck
> with the z-machine and its limits. If there was ever an underlying system
> that wasn't devoted to the beginner, this is it. I think Inform 7 would
> have been better breaking with its past and creating a new VM, something
> more powerful like T3.
See, I'm not sure how much of a sticking point this is for me. I hear people
say this a lot. I think it's a valid issue but I'm not sure how often it
actually affects people. In other words, how many people actually have been
stuck in finishing their game because of the limitations of a given system
(or virtual machine)? [I really would be curious to know.]
I can relate this to my own experiences. I've long been working with Inform
7 and TADS 3, drawing comparisons here and there. Personally, I find them
both very strong in a lot of areas. There are some things I've found easier
to do in TADS 3, although expressively it might have required more
programming code that Inform 7 hid from me. I've found other things that are
mcuh easier, initially, to do in Inform 7 in terms of expressing what I
wanted to do. All of that, however, is a construct of the language: not the
underlying virtual machine. I can often do very similar things in both
languages, once I learn how to express what I want to do.
One example I can talk about is dealing with the UNDO command. In a game
idea I was playing around with, I want to be able to respond with a message
after an UNDO command is issued. Further, I want to respond with one type of
message if the UNDO was issued after an "end game" and another message if
the UNDO was issued mid-game (i.e., not at an "end game" situation). I found
I Could do this very easily in TADS 3 although "very easily" might seem a
misnomer to someone who looked at the code at a glance. I found this was
quite a bit "trickier" in Inform 7, although it wasn't actually all that
much more code (in a line by line comparison). [I say "code" here because I
had to drop to I6 so I could do a more reliable comparison between the TADS
3 code.]
I will say the TADS 3 aspect seems to work a little more reliably *in this
one particular case*. I could draw conclusions, I suppose, about the
Z-Machine (or G-Machine) vs. T3 from this one example. I could also realize,
however, that what I'm trying to do really isn't all that standard, from
what I've seen. So saying one VM isn't all that "powerful" because it made
it harder to do this one, particular, relatively-non-standard thing I wanted
to do doesn't seem all that fair to me.
- Jeff
Eric
So you're saying the VM does not at all constrain what can be done in the
language? I'm confused.
Eric
news:b_SdnUcVKuL9GVHY...@comcast.com...
> I will say the TADS 3 aspect seems to work a little more reliably *in this
> one particular case*. I could draw conclusions, I suppose, about the
> Z-Machine (or G-Machine) vs. T3 from this one example. I could also
> realize, however, that what I'm trying to do really isn't all that
> standard, from what I've seen. So saying one VM isn't all that "powerful"
> because it made it harder to do this one, particular,
> relatively-non-standard thing I wanted to do doesn't seem all that fair to
> me.
Okay, so what if the thing you want to do isn't 'relatively-non-standard'?
You're sort of coming to the conclusion you want because you picked one
example that you're saying isn't a good example anyway because it's
non-standard or not something most people would do.
Khelwood
Nope. I'm saying that there is no limit in Glulx that would prevent
you writing NPC features similar to those present in adv3.
Jeff Nyman
> Okay, so what if the thing you want to do isn't 'relatively-non-standard'?
> You're sort of coming to the conclusion you want because you picked one
> example that you're saying isn't a good example anyway because it's
> non-standard or not something most people would do.
Rather, the key point I was going for was to get you to think about this
question: "how many people actually have been stuck in finishing their game
because of the limitations of a given system (or virtual machine)?"
I then pointed out one example that I came across where maybe (*maybe*) this
would have been an issue for me because I found that Inform could not handle
this particular situation as reliably as TADS 3.
I pointed out that this situation, however, is not one that many people
would come across (perhaps) and not one that I would use in many of my
games. This idea I had was for a specific type of game being told in a
specific style of narration. If it wasn't for this extra bit of UNDO
twiddling that I thought would fit the narration, I would probably have not
run into any other issues that made me think of one system over the other.
Another example I could relate to is with walls. Inform has, for me, had a
rocky history of dealing with walls in a way that I find useful. One game
idea I have is predicated on the user being able to utilize walls in very
specific ways. This is something that TADS 3 allows me to do much easier.
Note, however, that unlike my UNDO example, which does get into some VM
innards (at least ultimately), this example with wall handling could
probably be handled with a library extension or with clever enough coding,
thus not speaking to the VM at all.
That last point is what I think draws people to conclusions about how
"powerful" a VM is when, in reality, you're just speaking to what constructs
are manifestly apparent in the library of the system (or in various
extensions to the library). So people choose a system that tends to have the
features they think they want more obviously visible, even if the other
system could accomodate those features just as well. Talking about Inform 7
and TADS 3, this is clearly an interesting issue (I think) because of
different philosophical approaches of both systems: Inform 7 tries to give
you a minimal initial world model; TADS 3 tries to give you a much more
extensive world model.
So, for me, TADS 3's challenge is mainly figuring out which *existing*
elements I should use and then figuring out how to get those elements to do
what I want. Inform 7's challenge is *adding* the elements of the world
model that I want and then figuring out how to get those elements to do what
I want. (And the "existing" and "adding" gets muddied when you start
considering the various extensions.)
- Jeff
d...@pobox.com
>
> So you're saying the VM does not at all constrain what can be done in the
> language? I'm confused.
That's right. The underlying VM, Z-machine or Glulx, imposes
essentially no constraints on what you can do in the language. You're
confused because you've never written a compiler.
Z-machine, and Glulx even more so, is admirably free of IF concepts.
The VM knows nothing about directions, maps, NPCs, actions,
relations. All of these things have a _representation_ in the VM, but
that representation is chosen by the compiler, with some consideration
of what operations the VM efficiently implements.
The VM is much like a normal hardware architecture. You should read
the Glulx spec. It might give you a much better idea of how
impressive a feat Inform 6 and Inform 7 are.
drj
Eric
news:1171036745.1...@l53g2000cwa.googlegroups.com...
I'm not saying they're not impressive. So then is everyone around here who
thinks the T3 VM and language more powerful just totally mistaken?
Khelwood
You're talking as if the VM and the language were the same thing.
There is a persuasive case that the TADS 3 language is more powerful.
That's not the same as thinking that Inform would be better compiling
to a different VM.
Eric
But if the VM imposes no constraints on the language, like drj said, then
why is this case. It would mean that the TADS 3 language and Inform language
are equally powerful.
Everyone's telling me I was wrong to focus on the VM. But then indicating
that the languages are just as powerful. So then how is TADS 3 more
powerful?
Khelwood
> "Khelwood" <Khelw...@gmail.com> wrote in message
>
> news:1171040773....@p10g2000cwp.googlegroups.com...
>
>
>
> > On 9 Feb, 16:57, "Eric" <-> wrote:
> >> <d...@pobox.com> wrote in message
>
> >>news:1171036745.1...@l53g2000cwa.googlegroups.com...
>
> >> > On Feb 9, 2:27 pm, "Eric" <-> wrote:
> >> > The VM is much like a normal hardware architecture. You should read
> >> > the Glulx spec. It might give you a much better idea of how
> >> > impressive a feat Inform 6 and Inform 7 are.
>
> >> > drj
>
> >> I'm not saying they're not impressive. So then is everyone around here
> >> who
> >> thinks the T3 VM and language more powerful just totally mistaken?
>
> > You're talking as if the VM and the language were the same thing.
> > There is a persuasive case that the TADS 3 language is more powerful.
> > That's not the same as thinking that Inform would be better compiling
> > to a different VM.
>
> But if the VM imposes no constraints on the language, like drj said, then
> why is this case. It would mean that the TADS 3 language and Inform language
> are equally powerful.
No it wouldn't, because the style and limitations of those languages
are not predominantly determined by the VM, but by the approach of the
people who designed the languages. The languages have different
strengths because they are written by different people with different
goals.
Jim Aikin
>> That's not the same as thinking that Inform would be better compiling
>> to a different VM.
>
> But if the VM imposes no constraints on the language, like drj said, then
> why is this case. It would mean that the TADS 3 language and Inform
> language are equally powerful.
No, you're confusing apples, oranges, and bananas. Let's see if I can come
up with a persuasive analogy.
The Virtual Machine is like an automobile. The language is like the driver.
The library is like the spectacles and gloves the driver happens to be
wearing. If the spectacles have opaque spots, the driver will have trouble
navigating, and if the gloves are stiff or slippery the auto will appear to
be difficult to control.
I'm not enough of a computer whiz to tell you the differences between the
TADS 3 VM and the Z-machine or Glulx-enhanced VM. But I can tell you that
the TADS 3 library is more powerful than the Inform 6 library. In addition,
the TADS 3 language contains tools and constructs that the Inform 6 language
lacks.
You could, as other posters have said, write your own library for Inform,
creating features that would do much or all of what TADS 3 will do. It would
be a lot of work. Or you could write your own language (i.e., compiler) that
would compile to the Z/Glx VM, and then write a library in your own
language. That would be even more work.
> Everyone's telling me I was wrong to focus on the VM. But then indicating
> that the languages are just as powerful. So then how is TADS 3 more
> powerful?
Uhh, are you asking about the TADS 3 language or the TADS 3 library?
The T3 language allows for the creation of macros that make it a bit easier
to write code. It has a few nice tools for handling lists. I'm sure there
are other elements, but I'll leave it for those who are more knowledgeable
than I to mention them.
The library has a hefty supply of classes and methods -- so many that you'd
really need to download and read the documentation to learn about them.
You're asking good questions, but the topic is complex. Hope this helps.
--JA
Jim Aikin
"Jeff Nyman" <jeff...@gmail.com> wrote in message
news:b_SdnUcVKuL9GVHY...@comcast.com...
> See, I'm not sure how much of a sticking point this is for me. I hear
> people say this a lot. I think it's a valid issue but I'm not sure how
> often it actually affects people. In other words, how many people actually
> have been stuck in finishing their game because of the limitations of a
> given system (or virtual machine)? [I really would be curious to know.]
Stuck, no. Affected, possibly.
After releasing version 1 of "Last Resort" in I6, I decided it needed a
rewrite, and switched to TADS 3. Porting the whole game is a huge job --
gawd, I'd be done by now if I'd done it the easy way -- but one of the main
reasons I switched rather than simply expand the existing code was because
testers had reported two or three serious but intermittent bugs that
appeared absolutely impossible. A flag that was referred to in my source in
only three places was apparently being reset between turns (or else read
wrongly), when no action by the player could possibly have caused it to be
reset. I don't _know_ that this was because of something in the VM, but it
worried me.
I felt that I was less likely to run into obscure, untraceable problems with
a system in which one designer (Mike Roberts) was directly involved with the
library, the compiler, and the VM than with a system like Inform, where the
language comes from one person, the Glulx spec from another person, and the
actual terps from yet other people.
--Jim Aikin
Eric
news:eqib6j$vg6$1...@aioe.org...
>
> The Virtual Machine is like an automobile. The language is like the
> driver. The library is like the spectacles and gloves the driver happens
> to be wearing. If the spectacles have opaque spots, the driver will have
> trouble navigating, and if the gloves are stiff or slippery the auto will
> appear to be difficult to control.
>
> I'm not enough of a computer whiz to tell you the differences between the
> TADS 3 VM and the Z-machine or Glulx-enhanced VM. But I can tell you that
> the TADS 3 library is more powerful than the Inform 6 library.
Okay, but *could* the Inform 6 library be as powerful as the TADS 3 library
if someone built it up? Since it doesn't depend on the VM, the answer must
be yes, right? But if that's the case, the TADS 3 library really isn't more
powerful, right? You just mean it's more powerful as its written, which
would imply that a less powerful library is written for Inform.
Andy Leighton
> "Jim Aikin" <edi...@musicwords.net> wrote in message
> news:eqib6j$vg6$1...@aioe.org...
>>
>> The Virtual Machine is like an automobile. The language is like the
>> driver. The library is like the spectacles and gloves the driver happens
>> to be wearing. If the spectacles have opaque spots, the driver will have
>> trouble navigating, and if the gloves are stiff or slippery the auto will
>> appear to be difficult to control.
>>
>> I'm not enough of a computer whiz to tell you the differences between the
>> TADS 3 VM and the Z-machine or Glulx-enhanced VM. But I can tell you that
>> the TADS 3 library is more powerful than the Inform 6 library.
>
> Okay, but *could* the Inform 6 library be as powerful as the TADS 3 library
> if someone built it up?
When Jim says "more powerful" he means implements a more complete world
model and understands a larger core vocabulary.
So, yes if someone wanted to they could create a replacement library
for Inform that had the same features as the Tads one.
However there exists a difference in philosophy between the designers
of Tads and Inform. The languages are different with slighly different
goals. This is a matter of routine. We see it all the time in the
computer programming field where there are 100s of languages.
I don't know the people who wrote Tads or Inform (or any of the other
IF implementation languages) but I would say having multiple competing
implementation systems with different design goals is a good thing
overall. Which system you eventually choose will, in the end, be a
matter of personal taste.
--
Andy Leighton => an...@azaal.plus.com
"The Lord is my shepherd, but we still lost the sheep dog trials"
- Robert Rankin, _They Came And Ate Us_
Neil Cerutti
> Okay, but *could* the Inform 6 library be as powerful as the
> TADS 3 library if someone built it up?
Yes. There are even two(?) 3rd-party Inform libraries to choose
from. Platypus is one, and I can't remember what the other one
is.
> Since it doesn't depend on the VM, the answer must be yes,
> right? But if that's the case, the TADS 3 library really isn't
> more powerful, right? You just mean it's more powerful as its
> written, which would imply that a less powerful library is
> written for Inform.
The TADS 3 VM may have more features, but that make it more
powerful only in a limited sense. Any feature provided by a VM
could instead be provided by a compiler.
A good example is the object systems used in early Inform
versions, today's Inform, and the Glulx version of Inform. The
Z-machine natively supports an object system and the tree that
holds them together. Every object can have a limited number of
properties. With the introduction of so-called "individual"
properties (Inform 5?), the feature of properties was moved
largely away from what the Z-machine provides natively. This
allowed Inform to support many more properties than the Z-machine
supports. And today Inform can also compile code for the Glulx
VM, which provides virtually no native support for objects.
--
Neil Cerutti
To succeed in the world it is not enough to be stupid, you must also be well-
mannered. --Voltaire
Victor Gijsbers
> I'm finding that no matter what gloss you put over it, you're still stuck
> with the z-machine and its limits. If there was ever an underlying system
> that wasn't devoted to the beginner, this is it. I think Inform 7 would have
> been better breaking with its past and creating a new VM, something more
> powerful like T3.
Could you perhaps give us some examples of getting stuck with the
z-machine and its limits? I got stuck with the z5-format once, because
my game became bigger than 256k, but switching to the z8 format took
care of that. Given that Glulx games can be up to several gigabytes, I
very much doubt that any author will _ever_ be troubled by its limits.
(Unless you are perhaps talking about limited graphical abilities? But
if you wanted to design a graphical game, Inform would be a rather
strange choice anyway.)
Let me try to chime in on the virtual machine vs language vs library
issue. Here's how this stuff works.
* A language is a set of instructions for a compiler about how to handle
source code. A language is not a file; it cannot be on your computer; it
is a specification.
* A compiler is a program that takes your source code and possibly some
libraries as input, and procudes an executable file as output.
* An executable file is a file that can be run on a machine (which is a
bit of an anachronistic word). You could have a Windows-executable, a
Linux-executable, a SuperNintendo-executable or a Z-machine-executable,
for instance.
* Instead of running an executable file on a machine, you can run it on
a virtual machine or emulator. This is kind of a fake computer simulated
by your real computer. Thus, I can run executables for the SuperNinentdo
on my Windows computer using a VM. I can run executable for the
Z-machine on my Linux-computer using a VM.
* Since there are no Z-machine computers, every Z-code game will be run
on a virtual machine.
* A library, finally, is a bunch of standard source code that the
compiler adds to your own source code before compiling your game.
The process of writing and playing a Z-code game is thus the following:
[Source code, written using the I7 conventions]
||
||
\/
[Standard I7 library] is added
||
||
\/
[Compiler, written using the I7 conventions] compiles your game to a
Z-code executable
||
||
\/
[Virtual machine, implemented on another machine] runs the executblae.
I hope that clears things up a bit. There are thus 2 programs, 2 bits of
code and 2 specifications involved: the compiler (a program), the
implementation of the VM, like WinFrotz (a program), the source code
(some code written by you), the library (some extra code), the Inform 7
language (a specification) and the Z-machine specification (a
specification).
You could write a different library to be used with the same compiler;
you could write a compiler that compiled Inform 7 code to the TADS
virtual machine; and so forth. These things are all largely independent.
Now, the Inform story is actually a bit more complex, since Inform uses
two compilers, but let's not worry about that.
Regards,
Victor
Adam Thornton
>But the constructions you're eventually allowed to create in the language
>have to be translated into forms that the VM can understand and if the VM is
>limited in the kinds of constructions it can understand, doesn't that mean
>it can constrain how things like NPCs are created? Or what can be done with
>the data structures that allow NPCs?
I'm sure both TADS3 and zcode are Turing-complete, and TADS3 and Glulx
have large enough memory spaces that they don't present a practical
problem.
Adam
Adam Thornton
>"Khelwood" <Khel...@gmail.com> wrote in message
>that the languages are just as powerful. So then how is TADS 3 more
>powerful?
TADS3 has a lot more complexity in its libraries, allowing you to pick
classes to get all sorts of pretty-sophisticated behavior right out of
the box, *if* you have waded through the documentation enough to
understand which class you want to use, and then figure out how to use
it in the right way to get the effects you want.
On the other hand, Inform (6 or 7) pretty much assumes you're going to
write your own special-case classes to get the behavior you want, which
means you can create things that do what you need them to with much
simpler interfaces than TADS, which tries very hard to be all things to
all people.
It's really just a matter of which style you prefer.
Adam
Adam Thornton
>Okay, but *could* the Inform 6 library be as powerful as the TADS 3 library
>if someone built it up? Since it doesn't depend on the VM, the answer must
>be yes, right? But if that's the case, the TADS 3 library really isn't more
>powerful, right? You just mean it's more powerful as its written, which
>would imply that a less powerful library is written for Inform.
This is essentially correct.
But "as it's written" is pretty much what you've got [*]. I mean, I
*could* take the words in the English language and arrange them into the
Best Novel Ever, but don't hold your breath.
Adam
[*] RAIF-POOL with the -Loptative flag on compilation excepted, of course.
Eric
It all comes down to how you prefer to write IF because the systems are
largely the same, at least in terms of overall capabilities. If TADS 3 seems
more powerful that's just because of the up-front work done on the library,
which is more complex. Inform 7 is just as complex but it doesn't appear
that way because it's not written that way.
In any event, T3 vs. z-machine vs. g-machine isn't really an issue at all.
Adam Thornton
I would almost agree.
Z-machine is the odd one out there, and it *can* be restrictive (my WIP
outgrew z8 pretty fast). But in practice it doesn't matter, because
Inform (either 6 or 7) can change from compiling to zcode to compiling
to glulx with one flag passed to the compiler.
Adam
-
Agreed.
Consider also that TADS programs are 3GL programs, I7 programs are
(mostly) 4GL programs. I7 allows the writer to descend (?) into the 3GL
space as desired. It also exposes 3GL constructs (If/Then/Else & various
loop constructs) for use as desired.
I like to think of I7 as an analog language, and TADS as a digital
language. I find a useful heuristic is that a 3GL algorithm describes
/what/ to do and /how/ to do it. A 4GL algorithm describes /what/ to do;
the /how/ is left to the (what we're calling for the purposes of this
thread) library.
Wikipedia has some useful definitions:
http://en.wikipedia.org/wiki/Third-generation_programming_language
and
http://en.wikipedia.org/wiki/Fourth-generation_programming_language
vaporware
Actually, I'd argue that the Z-machine VM has had a very significant
influence on the style and limitations of Inform 6.
Many of Inform's limitations are directly linked to those of the Z-
machine. For example, each Z-machine opcode can take its operands from
the stack, from a variable, or as constants. This translates directly
into Inform's limit on the number of local variables (the VM maintains
variables #1-#15 as locals automatically) and global variables (the VM
maps #16-#255 to certain locations in memory). Same with the limit on
the number of attributes.
Inform has no support for numbers that don't fit the VM's native types
- no floating point types, and no 32-bit integers on the Z-machine.
Inform has no support for dynamically allocating data, to create new
objects or pass around variable-length structures like strings and
lists, because the Z-machine doesn't support it natively, and
supporting it in the library would be complicated. TADS code allocates
new values all the time because the VM supports it natively (or
perhaps the TADS VM supports it natively because the language requires
it).
These limitations can all be worked around by writing enough code, but
to use them effectively and easily would require changes to the
language.
vw
Jim Aikin
> language. I find a useful heuristic is that a 3GL algorithm describes
> /what/ to do and /how/ to do it. A 4GL algorithm describes /what/ to do;
> the /how/ is left to the (what we're calling for the purposes of this
> thread) library.
Eek. Would I trust a library to know how to do everything that my story
requires? I don't think so. Not unless the library had been designed by
someone who not only COULD read my mind and predict the future, but had
actually done so.
That being the case, I probably wouldn't want to work in a 4GL.
--Jim Aikin
greg
> The VM is much like a normal hardware architecture.
However, this is a kind of limitation -- in some ways
it's too low level to easily support some things that
are desirable to have in an IF language. For instance,
it has no direct support for dynamic data structures.
Although it doesn't *have* to, in practice this has had
an effect on the language. I6 and I7 have no dynamic list
data type, because it's difficult to implement on the
Z-machine or Glulx. They don't provide any way of creating
new objects at run time, for similar reasons.
You might think these things aren't very important for
IF, but I'd say you're wrong. Anything that helps you
think at a higher level of abstraction is useful in any
kind of programming endeavour.
Parsing a command, for instance, requires dealing with
lists of words. In a language where dynamic lists are
a fundamental data type, this is very easy. In I6, you
have to declare an array, and decide in advance how big
it's going to be, putting a limit on how long a command
the player can type -- even if his computer has no
shortage of memory. Not to mention all the mental overhead
of having to think about these low-level details instead
of just getting on with implementing your parsing
algorithm.
Even if things like this are only done in the library,
and not by game authors, it's still important to have
a powerful language, because if it's hard to write
powerful libraries, it's less likely that they will be
written. I think this is one of the reasons that the
TADS library is bigger and more powerful than that of
I6 or I7 -- because the language makes it *easy* to
write powerful libraries.
If Graham had designed I7 based on something more like
the TADS VM, which is built around the concept of dynamic
data structures from the ground up, it would have been a
very different style of language. And, I would argue,
a more powerful one.
--
Greg
Richard Bos
> "Khelwood" <Khel...@gmail.com> wrote in message
> > Nope. If someone were to write the libraries you could do much the
> > same thing in Inform.
>
> So you're saying the VM does not at all constrain what can be done in the
> language? I'm confused.
Similarly that the processor does not at all constrain what can be done
on a computer, yes. Whether your computer has a PPC or a Pentium inside,
you can still run both InDesign and M$ Excel on it.
Richard
d...@pobox.com
> d...@pobox.com wrote:
> > The VM is much like a normal hardware architecture.
>
> However, this is a kind of limitation -- in some ways
> it's too low level to easily support some things that
> are desirable to have in an IF language. For instance,
> it has no direct support for dynamic data structures.
So? Extremely dynamic languages, like Lisp say, get implemented on
stock hardware all the time. I happen to be in the middle of a small
project to replace the garbage collector in a widely available Lisp
implementation. The architecture doesn't provide convenient
primitives for allocating memory or managing it in the garbage
collector, but that's not really a problem, one just gets on and does
it.
If one so desired I don't think it would be difficult to create a
dynamic language with garbage collection that ran on Glulx. Z-machine
might be slightly trickier, but only because of its size limitations
really.
>
> Although it doesn't *have* to, in practice this has had
> an effect on the language. I6 and I7 have no dynamic list
> data type, because it's difficult to implement on the
> Z-machine or Glulx. They don't provide any way of creating
> new objects at run time, for similar reasons.
I'd say there was a bit more of a two-way flow between the language,
Inform 6, and the VM Z-machine and Glulx. I think the impossibility
of dynamic allocation in Z-machine became adopted as a language
principle in Inform 6. The language principle was then adopted as a
design principle which influenced the designs of Glulx and Inform 7.
Glulx does in fact have pretty much the minimal amount of support
necessary for dynamic allocation (the setmemsize instruction). Inform
7 makes heavy use of quantifiers, and I'm sure this has some influence
on how easy it is to add dynamic allocation.
>
> You might think these things aren't very important for
> IF, but I'd say you're wrong. Anything that helps you
> think at a higher level of abstraction is useful in any
> kind of programming endeavour.
Actually I completely agree with you. I regard the creation of IF as
not much different from any other programming endeavor. And you
therefore want all the constructs that are available in a Real
Programming Language. By which I mean Lambda.
> Even if things like this are only done in the library,
> and not by game authors, it's still important to have
> a powerful language, because if it's hard to write
> powerful libraries, it's less likely that they will be
> written. I think this is one of the reasons that the
> TADS library is bigger and more powerful than that of
> I6 or I7 -- because the language makes it *easy* to
> write powerful libraries.
I think this is not the case. I think the TADS library is big and the
Inform library is small because of the deliberately different design
philosophies of the their respective creators (and, to some extent,
the communities that use them). I think the design philosophies
influence the language and libraries that are created. Again, there's
a two-way flow, when you're in the middle of designing a language you
tend to only incrementally adjust your philosophy.
> If Graham had designed I7 based on something more like
> the TADS VM, which is built around the concept of dynamic
> data structures from the ground up, it would have been a
> very different style of language. And, I would argue,
> a more powerful one.
An interesting speculation, but I don't believe it. I think Inform 7
is an enshrinement of Graham's philosophy of how to create IF, and
that philosoophy doesn't include dynamic allocation.
drj
Eric
news:1171072153....@s48g2000cws.googlegroups.com...
That makes sense. I can't see how a language written for a specific VM can't
be limited by what the VM can do.
So here's another question: Let's say you write a language for a different
VM. Say you took Inform 6/7 and made Inform 8 but it compiles to some other
VM.
Is it true to say that it's the same language? If the answer is that you
have to change the language to accomodate the new VM, then that does mean
there's a huge connection between the VM and the language and that does mean
that the power of the VM does translate to the language.
Here's another question: there's a thing you can do in TADS about making
'transient' objects. Is that something that can be done in Inform? It looks
like it has do with the interpreters but since the interpreters are
encapsulating the VM, I'm curious to note if Inform supports something like
this. If it can't, that's not just because of the language, that's because
of the VM, right? But could the VM be made to support 'transient' objects?
Or is that beyond the z-machine or glulx abilities?
Poster
This whole thread is hilarious because you begin by complaining that I7
is too hard for newbies, and then you immediately launch into esoteric
discussions of Inform's virtual machine.
Non-sequitur?
-- Poster
www.intaligo.com Building, INFORM, Seasons (upcoming!)
Eric
news:9d2dnczs2pYyQlDY...@giganews.com...
What I said was that I kept hearing it was designed for beginners and I
don't feel that's the case. And did you notice how you have to keep track of
whether you're compiling to glulx or which z-machine version? Did you notice
the oddities you have to sometimes do to get something to work on both? So,
you know what, that does sort of get into the VM, doesn't it? Or to a
beginner anyway, you're not sure how much of the VM matters.
d...@pobox.com
> I'm finding that no matter what gloss you put over it, you're still stuck
> with the z-machine and its limits. If there was ever an underlying system
> that wasn't devoted to the beginner, this is it. I think Inform 7 would have
> been better breaking with its past and creating a new VM, something more
> powerful like T3.
What would this new VM look like? Can you point what important
differences it would have over Glulx? And in particular, can you
identify how a new feature in a new VM could support the creation of
more beginner friendly languages?
To put it another way, you say that "the z-machine and its limits [are
not] devoted to the beginner"; what do you mean exactly? Which
aspects of the z-machine do you think make Inform beginner unfriendly?
drj
Eric
news:1171120693.6...@j27g2000cwj.googlegroups.com...
The fact that you have to consider the VM at all. Such as using memory
economy or considering when it's necessary to compile to another VM (glulx).
Of the fact that sometimes you have to write in Inform 6 format and then you
have to figure out if you have to be 'bi-platform', which it looks like a
lot of the extensions had to consider. The fact that the VM has some of
those limits at all (such as number of properties or attributes, which the
T3 VM doesn't, for example). I know you can switch to glulx to remove those
limits but then you still get into issues about how the intepreters don't
all handle glulx the same way and that there's hints but those hints don't
have to be followed. So you don't know what you're game might look like.
Neil Cerutti
But allowing those influenced to have such a strong effect was a
design decision. It didn't have to be that way.
The strong influences that still remain likely stems from Inform
humbly beginning as an assembler.
--
Neil Cerutti
Neil Cerutti
> d...@pobox.com wrote:
>
>> The VM is much like a normal hardware architecture.
>
> However, this is a kind of limitation -- in some ways it's too
> low level to easily support some things that are desirable to
> have in an IF language. For instance, it has no direct support
> for dynamic data structures.
All that does is raise the barrier to implementation a little
higher. That barrier isn't nearly high enough to prevent the
implementation of such strucutres if it turned out they were
seen as sorely lacking.
> Although it doesn't *have* to, in practice this has had an
> effect on the language. I6 and I7 have no dynamic list data
> type, because it's difficult to implement on the Z-machine or
> Glulx. They don't provide any way of creating new objects at
> run time, for similar reasons.
>
> You might think these things aren't very important for IF, but
> I'd say you're wrong. Anything that helps you think at a higher
> level of abstraction is useful in any kind of programming
> endeavour.
I would say that it is helpful to be able to think at the correct
level of abstraction. Higher levels of abstraction aren't always
helpful; they sometimes obscure important details. A good example
of rampant over-abstraction is the difficulty of writing
efficient code in Common Lisp. You have to be quite chummy with
the implementation you're using to accomplish it.
> If Graham had designed I7 based on something more like the TADS
> VM, which is built around the concept of dynamic data
> structures from the ground up, it would have been a very
> different style of language. And, I would argue, a more
> powerful one.
I don't think that Graham's library design would change much with
a more dynamic language. His design notes on Inform 7 (which are
rapidly falling out of date, I suppose) contain many good reasons
other than difficulty of implementation for the bare-bones Inform
7 library.
It's true he wouldn't have needed to design the clunky object
creation and destruction system.
--
Neil Cerutti
d...@pobox.com
> <d...@pobox.com> wrote in message
>
> news:1171120693.6...@j27g2000cwj.googlegroups.com...
>
> > On Feb 9, 1:36 pm, "Eric" <-> wrote:
> > To put it another way, you say that "the z-machine and its limits [are
> > not] devoted to the beginner"; what do you mean exactly? Which
> > aspects of the z-machine do you think make Inform beginner unfriendly?
>
> The fact that you have to consider the VM at all.
This is an excellent point. A good example of how old-timers might be
blinded by years of convention.
I'm still surprised you mention it though. I think Inform 7 does a
good job of hiding the VM from the novice author. When you press "Go"
the game you wrote runs within the IDE, no-one need mention the VM in
order to explain this fact.
Obviously when a game is "delivered" (released to beta-testers for
example) the VM will have to be mentioned. But it takes a long time
to get a game to that stage, and beginners will have graduated by the
time they get there. Maybe.
Or are you talking about (using Inform 7 to deliver games to) novice
players? I would not expect a novice author to be a novice player,
thus an author ought to be familiar with at least that idea that a VM
exists (and possibly the idea that there might be more than one of
them).
> Such as using memory
> economy or considering when it's necessary to compile to another VM (glulx).
> Of the fact that sometimes you have to write in Inform 6 format and then you
> have to figure out if you have to be 'bi-platform', which it looks like a
> lot of the extensions had to consider. The fact that the VM has some of
> those limits at all (such as number of properties or attributes, which the
> T3 VM doesn't, for example). I know you can switch to glulx to remove those
> limits but then you still get into issues about how the intepreters don't
> all handle glulx the same way and that there's hints but those hints don't
> have to be followed. So you don't know what you're game might look like.
Are you claiming that novice authors have to decide which VM to
target, or write VM-specific code? I certainly wouldn't expect novice
authors to be creating extensions (not ones that actually get used).
I agree that these are complicated issues, but I don't see why a
beginner has to grapple with them.
"You don't know what you're game might look like" is a problem
commonly expressed by beginners. It's not a mistake to express that
desire, but the current ecosystem of IF systems have evolved in such a
way that they are poor at allowing author's to control exactly what
their game looks like.
drj
Eric
news:1171130747.6...@j27g2000cwj.googlegroups.com...
> On Feb 10, 3:26 pm, "Eric" <-> wrote:
>> <d...@pobox.com> wrote in message
>>
>> news:1171120693.6...@j27g2000cwj.googlegroups.com...
>>
>> > On Feb 9, 1:36 pm, "Eric" <-> wrote:
>> > To put it another way, you say that "the z-machine and its limits [are
>> > not] devoted to the beginner"; what do you mean exactly? Which
>> > aspects of the z-machine do you think make Inform beginner unfriendly?
>>
>> The fact that you have to consider the VM at all.
>
> good job of hiding the VM from the novice author. When you press "Go"
> the game you wrote runs within the IDE, no-one need mention the VM in
> order to explain this fact.
That's true. But it comes up in various ways, like when you have to ask what
"use memory economy" means or why you'd have to use it. Or why you'd have to
increase some MAX setting. Or what it means to switch to a glulx version and
then figure out what separate interpreter has to play that game outside of
the IDE. Chapter 17 of the manual has a section called "starting the virtual
machine." Chapter 19 of the manual has a section called "Virtual machines
and story file formats." So it's not like this is totally hidden from
people. Also many, many, many posts on this newsgroup lead to talk about the
"z-machine" and "glulx" --- and those are virtual machines.
> Are you claiming that novice authors have to decide which VM to
> target, or write VM-specific code? I certainly wouldn't expect novice
> authors to be creating extensions (not ones that actually get used).
> I agree that these are complicated issues, but I don't see why a
> beginner has to grapple with them.
Well, if you're a beginner you don't always know what you have to grapple
with, right? That's part of being a beginner. Everyone says don't worry
about it. Then you routinely come across things where people are 'worrying
about' it to the extent that start asking details about it. And if you
notice, even though everyone says the distinctions are so obvious, a couple
of people here disagree on points that seem pretty important at an overall
level. So maybe it's not all that obvious after all.
I bring ALL of this up because I never had any questions about the TADS 3 VM
when I was working on TADS 3. I wasn't even thinking of what a "VM" was at
that point. I just found it interesting that in Inform this all the sudden
became something that it seemed I had to know about somewhat.
JDC
>
> news:1171130747.6...@j27g2000cwj.googlegroups.com...
> But it [the VM] comes up in various ways, like when you have to ask what
> "use memory economy" means or why you'd have to use it. Or why you'd have to
> increase some MAX setting.
Just to nitpick a little: these two have little to do with the VM.
"Use memory economy" determines whether debugging code is added, and
doesn't depend on the VM, and many of the MAX settings refer to memory
use by the compiler, not the resulting game file.
-JDC
Jeff Nyman
> I bring ALL of this up because I never had any questions about the TADS 3
> VM when I was working on TADS 3. I wasn't even thinking of what a "VM" was
> at that point. I just found it interesting that in Inform this all the
> sudden became something that it seemed I had to know about somewhat.
I do find this a good point. Having worked on both systems quite a bit I can
at least throw my hat into this particular ring and say that I agree: you do
tend to focus on issues that are more related, ultimately, to the virtual
machine when you work with Inform for any length of time. Whether or not a
beginner should or should not have to worry about these aspects is largely
beside the point because, as you correctly point out, you don't always know
what is and is not of concern.
On the other hand, you are also asking for details here about the interface
of the language and the VM (and to what extent the design of one influences
the other) and this is generally not an issue that you have to worry about
when designing. It more is something you should think about when choosing
the system you want to work with. A beginner is somewhat isolated from this
aspect of consideration.
I think part of the issue is what you bring up here:
> many, many, many posts on this newsgroup lead to talk about the
> "z-machine" and "glulx"
Beginner's are inundated with a lot of stuff if they're perusing the
newsgroups as they learn. That will tend to bring up things that they might
not have focused on before they heard about it.
Part of the "confusion" may stem from the fact that with TADS 3 there is no
separation into a "z-machine" and a "g-machine." In other words, TADS 3
doesn't rely on a different VM to remove the limitations of another VM. To
that extent, I suppose you could argue that TADS 3 does insulate the user a
bit more from some of those aspects. (That said, you do still have to
consider how TADS 3 games will appear in interpreters that don't support the
full "multimedia" elements of what's called HTML TADS.)
- Jeff
Eric
news:1171132956.1...@v45g2000cwv.googlegroups.com...
But why should someone have to know that? So now I've got to worry about the
compiler and the VM?!!!! I get that these situations might be rare to some
people, but they aren't that rare because the manual says this:
"In case (a), Inform 6 will say that a memory setting has been exceeded: it
will say what this setting is called (for instance "MAX_ZCODE_SIZE") and
what its current value is (for instance 50000). We can then avoid the
problem by adding the following use option into the source text:
Use MAX_ZCODE_SIZE of 60000.
And similarly for every other Inform 6 memory setting. (If the source tries
to specify the same setting more than once - which is quite possible if
extensions are included, with rival ideas - then the highest value is used.)
In case (b), we must either switch to a larger story file format, or
economise. The simplest thing to do is to switch up from z5 to z8, and then
from z8 to Glulx, until no limits are reported any more. (Glulx has a huge
capacity, so we need never worry about size limits again.)"
It then goes on to talk about how you can specify "Use memory economy" in
this case. So I see "ZCODE" and I see "z-machine" and I see "Glulx" and
you're saying this has little to do with the VM and I'm not doubting you,
but just reading the manual sure seems to indicate that it does. And this is
all in chapter 2 so it's not like it's hidden away in some appendix that no
one's supposed to read anyway.
Eric
"Jeff Nyman" <jeff...@gmail.com> wrote in message
news:SPednVqIG9rCjlPY...@comcast.com...
> "Eric" wrote:
>
>> I bring ALL of this up because I never had any questions about the TADS 3
>> VM when I was working on TADS 3. I wasn't even thinking of what a "VM"
>> was at that point. I just found it interesting that in Inform this all
>> the sudden became something that it seemed I had to know about somewhat.
>
> interface of the language and the VM (and to what extent the design of one
> influences the other) and this is generally not an issue that you have to
> worry about when designing. It more is something you should think about
> when choosing the system you want to work with. A beginner is somewhat
> isolated from this aspect of consideration.
>
Okay so then no one answered my question earlier about the 'transient' stuff
with TADS 3. Since you and most everyone seems convinced that everything can
be done in one VM that's done in the other, can I do this 'transient' kind
of stuff in Inform? Since it all just comes down to how the language and
library are implemented, according to most of what I've read, then this
should be possible to implement, right?
d...@pobox.com
> I would say that it is helpful to be able to think at the correct
> level of abstraction. Higher levels of abstraction aren't always
> helpful; they sometimes obscure important details. A good example
> of rampant over-abstraction is the difficulty of writing
> efficient code in Common Lisp. You have to be quite chummy with
> the implementation you're using to accomplish it.
The usual problem in Common Lisp isn't abstraction, but dynamism.
It's hard for the compiler to do any reasoning about your code if a
random setf can legally change any of the functions you've defined.
That and the fact that the culture of using (declare (type ...)) and
(declare (ftype ...)) isn't very strong in the CL community.
drj
Eric Eve
"Eric" <-> wrote in message
news:bIednbtJ-4XjiFPY...@comcast.com...
> Okay so then no one answered my question earlier about the
> 'transient' stuff with TADS 3. Since you and most everyone seems
> convinced that everything can be done in one VM that's done in the
> other, can I do this 'transient' kind of stuff in Inform? Since it
> all just comes down to how the language and library are
> implemented, according to most of what I've read, then this should
> be possible to implement, right?
Perhaps this needs to be answered by someone more knowledgeable
about the z-code/glulx VMs than I am, but my guess would be that
you've put you're finger on a valid point: i.e. as I understand it
transient objects are only possible in TADS 3 because the TADS 3 VM
specifically allows for them, in which case there may be no easy way
(or possibly even no way at all) to emulate their functionality in
Inform.
-- Eric
Jeff Nyman
> Okay so then no one answered my question earlier about the 'transient'
> stuff with TADS 3. Since you and most everyone seems convinced that
> everything can be done in one VM that's done in the other, ...
Actually, I'm not one of those that's convinced that the nature of the
virtual machine does not have some constraining aspects on the overall
design of a language. It clearly does. Whether that's *necessary* or not is
another issue. The main goal is that a language has to be capable of
allowing a person to write something that a compiler can generate into a
form of "bytecode" that runs on that virtual machine. To that extent, I can
imagine writing a language (like Inform) a little differently but still
having it compile to a Z-machine readable format.
In fact, this does happen. That's how alternative libraries are built. Or
think of Hugo. Hugo is a lot like Inform in it's language structure,
borrowing a lot of the basic structure and ideas. It happens to compile to
another kind of virtual machine. But you could probably make it compile to
the Z-machine. It's just the compiler would have to be modified in order to
accomodate the changed language.
> can I do this 'transient' kind of stuff in Inform? Since it all just comes
> down to how the language and library are implemented, according to most of
> what I've read, then this should be possible to implement, right?
As far as this, I'm not entirely sure. It's definitely partly an issue that
the VM has to deal with. From the standpoint of a persistence mechanism both
TADS 3 and Inform 6/7 share that. That's the basis of things like the UNDO
that I mentioned before (or SAVE and RESTORE).
What TADS 3's VM has is a TadsObject intrinsic class (intrinsic, that is, to
the VM) that has a method that allows you to create a transient instance of
a given class and thus transient objects, where "transient" means the object
can survive (for lack of a better term) the persistence mechanisms (such as
those UNDO, SAVE, and RESTORE actions).
I do think the Z-machine or Glulx could do this, although speed may be a
factor. I think that TADS 3's VM handles this by essentially not marking
transient objects as part of a series of "checks" for persistence actions.
I'm not sure the extent to which this "check-ladder" system is in place in
either of Inform's virtual machines, but I think it could *effectively* be
done. (Whether it could be *efficiently* done is something I'm not sure of
at all.)
- Jeff
d...@pobox.com
> Okay so then no one answered my question earlier about the 'transient' stuff
> with TADS 3. Since you and most everyone seems convinced that everything can
> be done in one VM that's done in the other, can I do this 'transient' kind
> of stuff in Inform? Since it all just comes down to how the language and
> library are implemented, according to most of what I've read, then this
> should be possible to implement, right?
I don't know anything about transient in TADS 3 (sounds like (declare
(dynamic-extent ...)) in Common Lisp though), but I have issues with
your logic.
So far, we've been discussing whether the VM used by Inform 7
_necessarily prevents_ it from implementing some language feature.
That Inform 7 does not implement some feature is not evidence that the
VM prevents it from doing so. That's affirming the consequent. In
other words, even if Inform 7 didn't have something equivalent to
TADS3 transient, then that says nothing about the VM.
This question of what features the Inform 7 language presents is,
however, much more relevant than what underlying VMs are being used.
drj
Eric
news:1171135290.3...@h3g2000cwc.googlegroups.com...
> On Feb 10, 6:57 pm, "Eric" <-> wrote:
>> Okay so then no one answered my question earlier about the 'transient'
>> stuff
>> with TADS 3. Since you and most everyone seems convinced that everything
>> can
>> be done in one VM that's done in the other, can I do this 'transient'
>> kind
>> of stuff in Inform? Since it all just comes down to how the language and
>> library are implemented, according to most of what I've read, then this
>> should be possible to implement, right?
>
> I don't know anything about transient in TADS 3 (sounds like (declare
> (dynamic-extent ...)) in Common Lisp though), but I have issues with
> your logic.
>
> So far, we've been discussing whether the VM used by Inform 7
> _necessarily prevents_ it from implementing some language feature.
> That Inform 7 does not implement some feature is not evidence that the
> VM prevents it from doing so. That's affirming the consequent. In
> other words, even if Inform 7 didn't have something equivalent to
> TADS3 transient, then that says nothing about the VM.
But you just said you don't know anything about transient. So how do you
know that what I've just presented isn't evidence of a VM limitation? Maybe
you're right. But I'd feel better about that if both of us knew exactly how
transient was implemented. It doesn't sound like we do. So I'm not sure
either of us can come to a conclusion.
> This question of what features the Inform 7 language presents is,
> however, much more relevant than what underlying VMs are being used.
Yup, until the features the language presents tell you that you need to take
into account the underlying VM.
d...@pobox.com
> know that what I've just presented isn't evidence of a VM limitation?
Because I can use logic instead. Go and google for "affirming the
consequent".
Consider:
People that are allergic to cats cannot own cats.
Anne does not own a cat.
Does it necessarily follow that:
Anne is allergic to cats?
No, it does not, we can't deduce anything about whether Anne has a cat
allergy or not.
drj
Eric
news:1171136241.9...@m58g2000cwm.googlegroups.com...
Very impressive. But your first case isn't correct. People who are allergic
to cat's can own them. (I do. Or, rather, my wife does. I take medication.)
Secondly, that assumes something known about allergies and cats. We know
that people allergic to cats can have problems with their allegries. Here's
another one:
"Transient objects are part of the VM."
"Inform 7 doesn't have transient objects as part of the language."
Does it follow that Inform 7 can't implement transient objects?
We don't know if the first one (transient objects are part of the VM) is
true or not. So we can't ask what follows yet because we don't have our
facts. I'm asking about the first one, which is what I started asking.
d...@pobox.com
>
> with TADS 3. Since you and most everyone seems convinced that everything can
> be done in one VM that's done in the other, can I do this 'transient' kind
> of stuff in Inform? Since it all just comes down to how the language and
> library are implemented, according to most of what I've read, then this
> should be possible to implement, right?
I've now educated myself about TADS3 transient and declare myself an
expert. :) (it's an object that isn't subject to mutation by UNDO or
RESTORE)
Glulx: possible, but awkward. A specific single contiguous region of
memory would have to be permanently given over to transient objects
using the protect instruction. All transient objects would have to
live next to each other. Could get awkward when space needs to grow.
Z-machine: I don't know (I'm not so intimately familiar with the
spec), but I guess not.
So, I think you're right, Inform 7's affinity with Z-machine precludes
it from implementing transient.
In addition to which you make me realise the whole UNDO thing is a
point in your favour. It would be troublesome to implement a language
with UNDO (such as either TADS3 or Inform 7) on top of a system that
doesn't provide some support for it (such as typical real hardware).
Possibly troublesome to the extent that it wouldn't be done (witness:
the number of homebrew systems that don't implement UNDO).
But... transient objects and UNDO are hardly things that make a
language beginner friendly are they?
drj
Jeff Nyman
> Yup, until the features the language presents tell you that you need to
> take into account the underlying VM.
As fun as it might be to watch this devolve into who can come up with more
logical fallacies and how many counter-counter-counter-points we can all
generate, herein maybe is where a relevant point can at least let us all get
something tangible out of this.
If I understand the genesis of this conversation, it stemmed (partly) from
how you felt that while Inform 7 was touted as being more for beginners,
your experiences up to this point with it made you feel that statement was
either incorrect or a bit misleading. You've largely based this (it seems)
on the fact that Inform does tend to account for the underlying Z-machine
and/or glulx virtual machine more than does TADS 3 (which, you indicated,
never really made you focus on the T3 virtual machine).
So ..... what do you think could better help people with this?
For example, you mentioned the fact that chapter two of the Inform 7 manual
mentions aspects of the virtual machine. Would you suggest that this part
not be placed that early in the manual?
Would you suggest that the compilation process automatically takes into
account whether or not your game has to compile to the Z5, Z8, or Glulx
format? (This is something that I believe is up for discussion.)
In other words, you've pointed out a problem. Do you have any ideas for a
solution that might be workable for this class of people being referred to
as "beginners?"
The reason I ask this is because if you find you like TADS 3 better and
enjoy working with the language more, then why not stick to that? Maybe
Inform isn't for you. However, if you have a genuine desire to make Inform 7
live up to this claim of "beginner friendliness" (which is perilously vague
to me), I would suggest the conversation should turn to how do you think
these perceived problems can be overcome or at least mitigated a bit.
Part of this may also entail realizing that just because Inform 7 has some
overt references to its virtual machine, that does not, in and of itself,
mean it can't be user friendly or friendly to beginners. In fact, I could
make an argument that this is more friendly in that it's making sure I
understand how things work at a lower level as well as a higher level. I can
always choose to ignore this information if it's not relevant to me. (I
ignored much of the TADS 3 System Manual for this very reason: I just didn't
need to know at that time. I've ignored great swathes of the Inform 7 manual
until I find I care about what those parts are talking about.)
- Jeff
Krister Fundin
<d...@pobox.com> skrev i meddelandet
news:1171135290.3...@h3g2000cwc.googlegroups.com...
> I don't know anything about transient in TADS 3 (sounds like (declare
> (dynamic-extent ...)) in Common Lisp though)
Transient objects in TADS 3 are those that are unaffected by a
restore/restart/undo operation. The stack and the VM registers are
also transient.
-- Krister Fundin
Jeff Nyman
news:1171136764.2...@p10g2000cwp.googlegroups.com...
> But... transient objects and UNDO are hardly things that make a
> language beginner friendly are they?
I agree. This was largely the point I tried to make earlier on in this
thread about how a specific example I used (related to UNDO, in fact) was
easier to implement in TADS 3 than in Inform 7. However, two salient points:
(1) Both languages (and ultimately VM's) could handle what I wanted to do.
(2) My specific need was not something that I feel would be very commonly
used.
This is also why I originally asked: "...how many people actually have been
stuck in finishing their game because of the limitations of a given system
(or virtual machine)?"
I was trying to determine how much of an issue this might really be.
Transient objects: I'm not so sure. I can see why they might be interesting
in some aspects. The source code for "Return to Ditch Day" gives an example
of using a transient object for an initial game menu and I've long thought
about a time travel game that would have elements that could survive things
like UNDO and RESTORE actions (and maybe RESTART actions) to better simulate
paradox puzzles. It sounds like transient might fit that bill. (With both
TADS 3 and Inform, I was thinking I would have to write elements of the game
out to a file so that they could be read back in after a RESTORE or UNDO
operation but I was worried about this because of problems with writing
files on different platforms.)
- Jeff
d...@pobox.com
> That's true. But it comes up in various ways, like when you have to ask what
> "use memory economy" means or why you'd have to use it. Or why you'd have to
> increase some MAX setting.
Ah. Chapter 2.13 (Inform 7 4K40). Well, that should certainly be
moved to an appendix. One really does only need to know about that
stuff when the compiler tells you you've got a problem with it. And
in such a case the compiler could easily refer you to the right place
in teh documentation.
There's no real substitute for finding these sorts of glaring mistakes
other than getting a fresh beginning to go into the minefield and get
themselves blown up.
drj
vaporware
> "vaporware" <jmcg...@gmail.com> wrote in message
>
> news:1171072153....@s48g2000cws.googlegroups.com...
[...]
> > Actually, I'd argue that the Z-machine VM has had a very significant
> > influence on the style and limitations of Inform 6.
>
> That makes sense. I can't see how a language written for a specific VM can't
> be limited by what the VM can do.
>
> So here's another question: Let's say you write a language for a different
> VM. Say you took Inform 6/7 and made Inform 8 but it compiles to some other
> VM.
>
> Is it true to say that it's the same language? If the answer is that you
> have to change the language to accomodate the new VM, then that does mean
> there's a huge connection between the VM and the language and that does mean
> that the power of the VM does translate to the language.
I think it could be done without changing the language. Glulx is one
example - it's similar to Z in many ways, but the compiler still has
to deal with some significant differences.
> Here's another question: there's a thing you can do in TADS about making
> 'transient' objects. Is that something that can be done in Inform? It looks
> like it has do with the interpreters but since the interpreters are
> encapsulating the VM, I'm curious to note if Inform supports something like
> this. If it can't, that's not just because of the language, that's because
> of the VM, right? But could the VM be made to support 'transient' objects?
> Or is that beyond the z-machine or glulx abilities?
>From the Z-machine spec, it looks like this is possible in theory. The
object table is held in RAM, so it could be rewritten on the fly. The
main obstacle is managing the RAM. You'd need the compiler to leave
enough space at the end of the object table to fit in your new
objects, and you'd need other blocks of memory somewhere else to hold
their properties. Even then, you'd still be limited to a small number
of new objects, because the VM's address space is limited to 64k (much
of which is already taken up by other objects, arrays, etc.).
It's easier on Glulx, where objects are pointers instead of indices
into a table, the address space goes up to 4 GB, and dynamic
allocation is on its way to being built into the VM.
In either case, you'd still be at a disadvantage when it came to
garbage collection.
vw
vaporware
Well, that's true, but consider what has to be done to get around
those limitations. The attribute and property limitations are easy
enough (indeed, Inform 6 already gets around the Z-machine's limited
number of properties), as are global variables (I've written a patch),
but local variables are trickier.
If you stick to the Z-machine's limits on locals and parameters, you
get that storage space for free: the local variables live outside of
addressable RAM and don't count toward the 64k limit, and you can
recurse as much as you want, subject only to the interpreter's maximum
stack size. But if you want to exceed the limits, you have to set up
your own stack in RAM, which means every nested function call brings
you a little closer to that wall.
vw
vaporware
After reading the rest of the thread, I realize transient objects are
not the same as dynamically created objects. Whoops. You can protect a
chunk of memory from restoration in Glulx, but not Z.
vw
L. Ross Raszewski
It's worth pointing out that transient objects could indeed be handled
by just adding another layer of abstraction and replacing the hardware
Z-maching "object" notion with a data structure built in software.
Likewise, you could just write your own software-undo that allowed you
to preserve information. The limitation you can't work around is the
memory limit (which would, of course, be really really rough to stay
within once you were reimplementing the entire undo buffer at the
software level). It'd be incredibly difficult, but the library author
would only have to write it once.
That's rather what "turing complete" means.
And that's what the differences between VMs, and languages as well,
comes down to. Certain VMs and languages make certain things easier,
and other things harder. It's not what you can and can't do, it's
what is and isn't worth the effort of doing. TADS makes some things
easy, Inform makes other things easy. Historically, trying to make
*everything* easy has proven a fool's errand.
Graham Nelson
> That's right. The underlying VM, Z-machine or Glulx, imposes
> essentially no constraints on what you can do in the language.
This is far from being true, in fact, in that both architectures
impose constraints on the kinds of data structure which it is feasible
to handle with any efficiency (especially in terms of the stack, which
almost uniquely for VMs is not resident in the memory map and cannot
efficiently be accessed randomly). Still, yes, it's certainly true
that NPC handling, etc., has nothing to do with the underlying VM.
d...@pobox.com
wrote:
So don't use the stack provided by the VM. This is feasible for Glulx
at least. I may have some data on the performance of this approach
soon, but I don't see why it would be infeasibly inefficient.
drj
Graham Nelson
> Okay, but *could* the Inform 6 library be as powerful as the TADS 3 library
> if someone built it up? Since it doesn't depend on the VM, the answer must
> be yes, right?
Firstly, I don't think it is really sensibly to state as a fact that
either of these IF design systems is "more powerful" than the other,
partly because different users evidently judge differently, but mostly
because "powerful" is a somewhat ambiguous word. Power to do what?
Secondly, Inform and TADS use the term "library" slightly differently.
In the case of Inform, it means a low-level substrate of code
("substrate" is what Infocom used to call it) which handles basic
tasks at run-time. I6 users would interact with this fairly directly;
I7 users have most of that done for them, so that "the library" is
something which simply works by itself.
What I think you may mean is that TADS 3 has a large and well-
implemented suite of pre-written code to use in building IF. It
provides all kinds of facilities in a way that you can employ as
needed, doing so much as the standard library would for C, say. Inform
7 doesn't go down this more formal route at all (well, except to a
limited extent via the extensions mechanism). Instead, we provide
large quantities of sample code to be experimented with and borrowed
from, and the nature of the language is such that these can be mixed
fairly freely. This is one among many examples of how TADS 3 and
Inform 7 have chosen different paradigms.
> But if that's the case, the TADS 3 library really isn't more
> powerful, right? You just mean it's more powerful as its written, which
> would imply that a less powerful library is written for Inform.
I don't understand this argument at all, I confess. What are we aiming
to find out, or establish?
Graham Nelson
> I think the impossibility
> of dynamic allocation in Z-machine became adopted as a language
> principle in Inform 6. The language principle was then adopted as a
> design principle which influenced the designs of Glulx and Inform 7.
This is partly true. It's also the case that dynamic memory allocation
can be hazardous to the reliability of a story file. I6 (and still, to
some extent, I7) makes amazingly small story files, which run in very
memory-tight environments. Its current design means that no story file
can ever fail due to memory leaks or to different capacities of the
interpreters on different platforms. (With the sole, but not
completely trivial, example of the maximum stack capacity.)
Graham Nelson
> A flag that was referred to in my source in
> only three places was apparently being reset between turns (or else read
> wrongly), when no action by the player could possibly have caused it to be
> reset. I don't _know_ that this was because of something in the VM, but it
> worried me.
The chances of this being the Z-machine itself are low. (For one
thing, there are a dozen independent implementations of the Z-machine,
all written to a standard and checked against existing code with known
behaviour. If you suspect one of being wrong, compare against
another.)
It's possible that the library contained a bug which caused an array
to overflow? That should certainly be reported as a bug, but it
wouldn't be "the VM".
Graham Nelson
> And did you notice how you have to keep track of
> whether you're compiling to glulx or which z-machine version?
No need. Use the standard settings (i.e. the default) until one day,
when your game is large, Inform displays a page explaining that you're
out of space, but can get more by clicking a single check-box on the
Settings page. Follow this advice, and that's all you ever need to do.
Emily Short
wrote:
> On Feb 9, 5:47 pm, "Jim Aikin" <edi...@musicwords.net> wrote:
>
> > A flag that was referred to in my source in
> > only three places was apparently being reset between turns (or else read
> > wrongly),
> The chances of this being the Z-machine itself are low. (For one
> thing, there are a dozen independent implementations of the Z-machine,
> all written to a standard and checked against existing code with known
> behaviour. If you suspect one of being wrong, compare against
> another.)
>
> It's possible that the library contained a bug which caused an array
> to overflow? That should certainly be reported as a bug, but it
> wouldn't be "the VM".
I'm pretty sure Jim is referring to an issue with a Glulx game, and
did try to make comparisons but found it quite difficult to prove
where the error was.
d...@pobox.com
Indeed. And if I can paraphrase Jim, the problem wasn't so much that
the error was in the VM interpreter, or the library, or the compiler
output, the problem was that the separation of compiler, VM
specification, VM interpreter into 3 separate things implemented by 3
separate people (or 3 groups) led to a culture where it was difficult
to pinpoint obscure errors and easy for the buck to be passed around.
Compare this with TADS3 where you might get equally obscure errors,
but at least the buck is either with the author or with TADS3, so the
motivation to investigate isn't diluted so much.
drj
Graham Nelson
greg
> So? Extremely dynamic languages, like Lisp say, get implemented on
> stock hardware all the time.
When you're implementing a language on real hardware, you
don't have a choice -- something has to bridge the gap
between the language and the transistors.
But when a VM is involved, you have an extra degree of
freedom -- you get to choose where to place the boundary
between the language and the VM. The most successful
VM-based systems are the ones where the language and
the VM were designed together, with the boundary carefully
chosen to maximise the ease and efficiency of implementing
the language on the VM and the VM on the hardware.
When you try to implement a language on a pre-existing VM
that's ill-suited for the task, you end up with what
amounts to an interpreter on top of an interpreter, which
is not a recipe for efficiency.
> If one so desired I don't think it would be difficult to create a
> dynamic language with garbage collection that ran on Glulx.
Certainly it *could* be done, but the fact of the matter is
that it *hasn't* been done. Like it or not, the choice of
VM has influenced the design of the I7 language -- and not
just by way of one or two features being absent, but in
a very fundamental way.
> I think the impossibility
> of dynamic allocation in Z-machine became adopted as a language
> principle in Inform 6. The language principle was then adopted as a
> design principle which influenced the designs of Glulx and Inform 7.
That seems to sum it up pretty well. In other words,
everything is the Z-machine's fault. :-)
If you go right back to the beginning, I expect that
the Z-machine was designed to support ZIL, and Infocom
left dynamic allocation out of ZIL because they were
targeting machines with tiny memories, and wanted to
keep tight control over memory use. That probably made
good sense at the time, but in this day and age it makes
no sense at all.
> I think the TADS library is big and the
> Inform library is small because of the deliberately different design
> philosophies of the their respective creators
It's not really the size of the library I'm concerned with,
or even whether the code is in the library or in third
party extensions or written by the game author. It's a
matter of the level of sophistication of the code that
gets written. A high-level language gives you the ability
and confidence to tackle things that you would hesitate
to even attempt in a lower-level language.
As a result, it's more likely that a sophisticated piece
of code, such as an advanced NPC goal-seeking package,
will get written for a language like TADS with classes
and lists and hash tables as fundamental building blocks,
than for a language like I7 where you have to grunge around
with linear searches through fixed-size tables using
an unbelievably verbose syntax.
--
Greg
greg
> I6 (and still, to
> some extent, I7) makes amazingly small story files, which run in very
> memory-tight environments.
I wonder whether that's really so important nowadays. Even
handheld devices tend to have quite large memories now. And
when you start using Glulx, you're already abandoning any
hope of running it on a 64K Apple ][ or ten-year-old Palm
Pilot.
Also, I don't agree with the idea that dynamic memory
management equates to large memory requirements or extreme
danger of failure. For example, while it might be theoretically
possible for the player to take 5 million gumballs from the
vending machine and run out of memory, I'd say it's pretty
much his own fault if he does.
I also don't agree that lack of such guarantees the absence of
memory-related failures. E.g. getting a message that you have
"run out of maze" is pretty illusion-shattering, not to
mention quite silly when your machine probably has enough
memory to handle all the maze you would ever have the
patience to explore.
--
Greg
greg
> "Use memory economy" determines whether debugging code is added,
Shouldn't it be called "Use debugging code" or something,
then? That would make it clear what tradeoff is involved
in deciding whether to use it.
--
Greg
greg
> as I understand it
> transient objects are only possible in TADS 3 because the TADS 3 VM
> specifically allows for them, in which case there may be no easy way
> (or possibly even no way at all) to emulate their functionality in
> Inform.
As long as I7 relies on the Z-machine's built-in support
for undo management, it's probably not possible. It would
be possible if I7 didn't use that and made its own
arrangements about undoing. (Which might be desirable
for other reasons as well, such as supporting multi-level
undo.)
--
Greg
greg
> where "transient" means the object
> can survive (for lack of a better term) the persistence mechanisms (such as
> those UNDO, SAVE, and RESTORE actions).
The term "transient" seems a misnomer here, since it's an
object that survives *longer* than "non-transient" objects...
--
Greg
greg
> I would say that it is helpful to be able to think at the correct
> level of abstraction. Higher levels of abstraction aren't always
> helpful; they sometimes obscure important details.
That's true, but in my experience the optimum level of
abstraction for *most* programming tasks is somewhat
higher than that of fixed-size data structure management,
and IF programming certainly falls in this category.
> I don't think that Graham's library design would change much with
> a more dynamic language. His design notes on Inform 7 ... contain
> many good reasons other than difficulty of implementation for the
> bare-bones Inform 7 library.
Maybe it wouldn't have been any larger, but what there
is of it would likely have been much easier to write.
It might even have been *smaller* for the same functionality.
It may have been possible to provide more sophisticated
functionality for the same size. It may have been feasible
to write a whole new library instead of re-using the I6
one and thus inheriting many of its limitations.
--
Greg
steve....@gmail.com
> The term "transient" seems a misnomer here, since it's an
> object that survives *longer* than "non-transient" objects...
True. But, to quote from the TADS-3 docs:
This terminology can be confusing unless you have the right
perspective. If you think in terms of the running program, the
terminology seems backwards: transient objects seem more permanent
than the persistent ones, because they outlive operations like Restore
and Restart. Instead, think about persistence in terms of saving data
to a hard disk: persistent objects can be saved and restored, but
transient objects are fleeting, lasting only as long as the VM is
running.
Neil Cerutti
> d...@pobox.com wrote:
>> So? Extremely dynamic languages, like Lisp say, get
>> implemented on stock hardware all the time.
>
> When you're implementing a language on real hardware, you don't
> have a choice -- something has to bridge the gap between the
> language and the transistors.
>
> But when a VM is involved, you have an extra degree of freedom
> -- you get to choose where to place the boundary between the
> language and the VM. The most successful VM-based systems are
> the ones where the language and the VM were designed together,
> with the boundary carefully chosen to maximise the ease and
> efficiency of implementing the language on the VM and the VM on
> the hardware.
Which systems did you have in mind?
Python? Java? Pascal Pcode?
> When you try to implement a language on a pre-existing VM
> that's ill-suited for the task, you end up with what amounts to
> an interpreter on top of an interpreter, which is not a recipe
> for efficiency.
However, the Z-machine is not ill-suited to the task of running
an IF game.
>> If one so desired I don't think it would be difficult to
>> create a dynamic language with garbage collection that ran on
>> Glulx.
>
> Certainly it *could* be done, but the fact of the matter is
> that it *hasn't* been done. Like it or not, the choice of VM
> has influenced the design of the I7 language -- and not just by
> way of one or two features being absent, but in a very
> fundamental way.
The VM and resultant language have left a barrier that nobody
has felt the need to breech, although Andrew's recent malloc
extension to Glulx is likely to lower that barrier.
>> I think the impossibility of dynamic allocation in Z-machine
>> became adopted as a language principle in Inform 6. The
>> language principle was then adopted as a design principle
>> which influenced the designs of Glulx and Inform 7.
>
> That seems to sum it up pretty well. In other words, everything
> is the Z-machine's fault. :-)
>
> If you go right back to the beginning, I expect that the
> Z-machine was designed to support ZIL, and Infocom left dynamic
> allocation out of ZIL because they were targeting machines with
> tiny memories, and wanted to keep tight control over memory
> use. That probably made good sense at the time, but in this day
> and age it makes no sense at all.
Even if it were to get dynamic memory allocation, Inform still
wouldn't be a great language for composing fancy data structures.
It'd feel like using C, which would be OK for people like Zarf,
but difficult for a guy like me.
>> I think the TADS library is big and the Inform library is
>> small because of the deliberately different design
>> philosophies of the their respective creators
>
> It's not really the size of the library I'm concerned with, or
> even whether the code is in the library or in third party
> extensions or written by the game author. It's a matter of the
> level of sophistication of the code that gets written. A
> high-level language gives you the ability and confidence to
> tackle things that you would hesitate to even attempt in a
> lower-level language.
I agree there are many programmers who, when faced with the task
of writing, say, the Inform Standard Library in Inform, would
throw up their hands in despair. But how many of them would be
able to pull their hands back down simply because they had hash
tables and dynamic arrays?
--
Neil Cerutti
JDC
I think that Inform also normally adds some links between objects to
improve looping efficiency, which are also omitted when using memory
economy (again, independent of VM); I think there's a reference to
this in the change log. As you say, it would probably be useful to
have a clearer explanation of this in the documentation.
-JDC
Emily Short
> Indeed. And if I can paraphrase Jim, the problem wasn't so much that
> the error was in the VM interpreter, or the library, or the compiler
> output, the problem was that the separation of compiler, VM
> specification, VM interpreter into 3 separate things implemented by 3
> separate people (or 3 groups) led to a culture where it was difficult
> to pinpoint obscure errors and easy for the buck to be passed around.
> Compare this with TADS3 where you might get equally obscure errors,
> but at least the buck is either with the author or with TADS3, so the
> motivation to investigate isn't diluted so much.
My recollection is also that he wasn't able to isolate a case
demonstrating the problem in action, though, which makes it
challenging for anyone to investigate, however motivated they might
be.
(I'm not particularly in any stage of this loop, but my sense is that
there has in fact been movement on this kind of problem when the bug
has been reportable.)
greg
> Which systems did you have in mind?
>
> Python? Java? Pascal Pcode?
Smalltalk and Python come to mind. I wouldn't call Java
a great success, but for different reasons. The Pascal
P-system seems to have done pretty well in its day. .NET
seems to be a good match only for a fairly narrow class
of languages (e.g. Visual Basic -- good; Python, Haskell
or Prolog -- not so good).
> However, the Z-machine is not ill-suited to the task of running
> an IF game.
Maybe not, but it's ill-suited to the task of supporting
a language on the level of TADS or Python, which IMO are
better suited to the task of writing an IF game than one
like I6 or I7.
> Even if it were to get dynamic memory allocation, Inform still
> wouldn't be a great language for composing fancy data structures.
That's why I said it's not just a matter of bolting on a
feature or two. The language needs to be designed with a
different mindset from the beginning.
> I agree there are many programmers who, when faced with the task
> of writing, say, the Inform Standard Library in Inform, would
> throw up their hands in despair. But how many of them would be
> able to pull their hands back down simply because they had hash
> tables and dynamic arrays?
Of those capable of taking on the task at all, I'm sure
that more of them would be willing to tackle it with a
good set of tools at their disposal. I certainly would.
--
Greg
steve....@gmail.com
> Firstly, I don't think it is really sensibly to state as a fact that
> either of these IF design systems is "more powerful" than the other,
> partly because different users evidently judge differently, but mostly
> because "powerful" is a somewhat ambiguous word. Power to do what?
Firstly, I think it's a perfectly reasonable question to ask, which
design system is "more powerful," despite the fact that different
users judge differently, or, which is the same thing, despite the fact
that "powerful" is a word applied differently by different people.
> Secondly, Inform and TADS use the term "library" slightly differently.
False. If there's a difference at all, the difference is between I7
and I6/TADS. It is true that both I6 and TADS make the library
manifest to the user, while I7 packs it away. But its accessibility is
not relevant to what we call it; it means the same thing in any case.
It's the programmatic basis of the world model, the parser, the
default behavior. Probably the best way to think of it is as the IF
Engine. As you yourself explain:
> In the case of Inform [6], it means a low-level substrate of code
> ("substrate" is what Infocom used to call it) which handles basic
> tasks at run-time. I6 users would interact with this fairly directly;
> I7 users have most of that done for them, so that "the library" is
> something which simply works by itself.
But the library is written so that the user won't have to write an IF
Engine from scratch. The accessibility of the IF Engine is quite
distinct from how much work it's doing for the user. When you say that
"I7 users have most of that done for them," what do you mean by
"that"? I think you can only mean "basic run-time tasks" -- but I6
handles the same tasks. There is probably something interesting you
can say about the difference between I6 and I7, in their approach to
core IF Engines and their extension and support features, but this
ain't it, jingo.
> TADS 3 has a large and well-implemented suite of pre-written code
> to use in building IF. Inform 7 doesn't go down this more formal route[.]
I'd say I7 errs far on the side of *formal*, TADS-3 erring far on the
side of *functional* or *workable*. I6 and TADS-2 being somewhere in
the middle. That you say TADS-3 is *more formal* -- I find this just
bizarre; it's as if you're not thinking, only advertising. In fact,
I'm pretty convinced that's the case.
Eric Eve
news:1171148380.6...@v33g2000cwv.googlegroups.com...
> On Feb 9, 5:47 pm, "Eric" <-> wrote:
>> Okay, but *could* the Inform 6 library be as powerful as the TADS
>> 3 library
>> if someone built it up? Since it doesn't depend on the VM, the
>> answer must
>> be yes, right?
>
> Firstly, I don't think it is really sensibly to state as a fact
> that
> either of these IF design systems is "more powerful" than the
> other,
> partly because different users evidently judge differently, but
> mostly
> because "powerful" is a somewhat ambiguous word. Power to do what?
Perhaps what the OP (not to be confused with this Eric) has in mind
is that it would be possible to create an I6 library (in the sense
that Parser, Verblib and Grammar provide a standard library of
routines for I6 and adv3 does for TADS 3) with the same range of
functionality as adv3 (the TADS 3 standard library); here
"powerfulness" would refer not so much to the "power" of the IF
systems overall as to the functionality incorporated in their
libraries. IOW, I think the OP may be envisaging a replacement I6
library in the sense that Platypus is a replacement I6 library, but
one that duplicates the functionality of adv3. The OP's question is
then whether the VM would represent a barrier to doing this.
My guess is that the answer is yes and no; I doubt that a library
the size of adv3 would fit into the z-machine (or at least, whether
it would leave a worthwhile amount of headroom for game code). OTOH
there seems to me to be no reason in principle why such a library
could not be implemented in the I6 language and compiled to Glulx.
The supplementary question would then be whether the TADS 3
language contained features difficult to reproduce in I6 such as to
make such a hypothetical I6 library difficult or impossible to
implement. Again I suspect the answer would be yes and no; it might
be difficult to produce an exact translation of the adv3 library
into I6, but I suspect it would be possible to produce in principle
to produce something that was more or less functionally similar (for
example, shortly before I7 came out I was playing around devising an
I6 equivalant to the TADS 3 conversation system, and it certainly
seemed feasible to produce something along the same lines, even
though it wouldn't have turned out exactly equivalent).
To compare the power of two IF design systems it might be easier to
start with systems that are more obviously similar, for example TADS
2 and TADS 3. One might argue that TADS 3 is more powerful than TADS
2 on such grounds as:
(a) The TADS 3 language is effectively a superset of the TADS 2
language.
(b) TADS 3 makes it easier to work on multi-file projects (e.g.
through features such as separate compilation)
(c) The TADS 3 exposes more of the parser and the turn execution
cycle in the library, making it more possible for authors to modify
how these behave.
(d) The TADS 3 adv3 library has a far richer feature set than its
TADS 2 equivalent.
I suspect it would be perfectly possible to write a TADS 2 library
that reproduced all or most of the functionality of the TADS 3
library, it would simply be pointless (why would anyone want it in
preference to TADS 3 given the other advantages of TADS 3?).
Here the comparison is fairly straightforward since one is more
obviously comparing like with like, and can point to fairly
objective features of both systems. Possibly the principles gleaned
from such an exercise could then be applied to a comparison of TADS
3 with other systems.
That said, "powerful" could also have a far more subjective meaning,
effectively answering the question "how easy do I find it to make
this system do what I want?" The answer to this question may be as
much (or more) dependent on the experience and inclinations of the
author as the instrinsic nature of the systems. Or "powerful" could
have almost the reverse subjective meaning, answering the question
"how far do the capabilities of this system exceed what I have so
far mastered?" (the underlying assumption that I take what I have
mastered for granted as being transparent, and so perceive the
remaining functionality of the systems as an index of its power).
So yes, the term "powerful" is not entirely clear and can be
construed in more than one way, but I think in the OP's question it
basically refers to the size of the library (in the sense of adv3 vs
Parser, Verblib etc.).
-- Eric
Blank
> "Khelwood" <Khel...@gmail.com> wrote in message
> news:1171040773....@p10g2000cwp.googlegroups.com...
>>>
>>>> On Feb 9, 2:27 pm, "Eric" <-> wrote:
>>>> The VM is much like a normal hardware architecture. You should read
>>>> the Glulx spec. It might give you a much better idea of how
>>>> impressive a feat Inform 6 and Inform 7 are.
>>>> drj
>>> I'm not saying they're not impressive. So then is everyone around here
>>> who
>>> thinks the T3 VM and language more powerful just totally mistaken?
>> You're talking as if the VM and the language were the same thing.
>> There is a persuasive case that the TADS 3 language is more powerful.
>> That's not the same as thinking that Inform would be better compiling
>> to a different VM.
>
> But if the VM imposes no constraints on the language, like drj said, then
> why is this case. It would mean that the TADS 3 language and Inform language
> are equally powerful.
>
> that the languages are just as powerful. So then how is TADS 3 more
> powerful?
>
>
While there are some differences in capabilities of the different
languages - TADS for example can do floating point arithmetic, whereas
Inform only does integer arithmetic - most of the differences in IF
languages come from the standard libraries.
The libraries of TADS (both 2 and 3) and Inform (both 6 and 7) come from
different philosophies about how best to represent the game world to the
player. When the player does what the author has anticipated, then life
is sweet. But when the player does something unexpected - then what? I
think all IF authors are united in the assumption that an IF piece
should provide sensible answers to sensible actions, but what exactly
does "sensible" mean in this context?
The driving assumption behind TADS is that the best way to provide a
good game playing experience for the player is to simulate the 'real
world' (or at least 'a world' where physics is much the same as here) -
that way when the player does something the author has not anticipated
the game's responses will at least be sensible (if not very
interesting.) Tads provides a complex world right out of the box - for
example it provides ready-made 'bed' and 'chair' objects which provide
sensible default actions. If you try to lie down on a standard TADS
chair, you'll be told that you can't lie down on a chair.
Inform, by contrast, works with a very stripped-down world model. Beds,
chairs, thrones and balconies are all the same thing to Inform - they're
supporters. It's up to the author to provide the text which
distinguishes one from the other in the game world. The assumption is
that the game is not simulating a world, but is something analogous to a
film set. If you walk around the back of a set, you can see all the
strings and pulleys and whatnot - it's obviously fake.
Now it may seem at first glance that the TADS approach is obviously
superior - surely every time the player becomes aware of gameworld
mechanics, that's some kind of failure?
Well, yes and no. First of all, I'd point out that TADS' comparatively
complex world model comes at a price: a longer and possibly steeper
learning curve for authors (Jim could probably usefully chip in here),
plus of course the issue that the bigger and more complex a library, the
harder bugs are to find and crush.
Secondly I'd point out that other forms of entertainment display the
boundaries of the fictional world without it being considered a problem
- if you glance up from the page, you're back in Mundania; if you talk
to the characters on the screen, they don't reply to you - yet people
enjoy books and TV shows nonetheless. Understanding that the cutlery on
the tables in a restaurant scene is just 'moulded on' and can't really
be used doesn't necessarily detract from enjoying a story any more than
a seat on the left or right hand side of an auditorium which makes
obvious the false perspective in the stage set.
More subtly there is the cost of guaranteeing solvability: a major
difference between the game world and the real world is that there
really *is* a plot, and what's more the player is promised there is at
least one complete solution. Now it seems that having a realistic world
model is a good thing because it can provide 'extra' solutions to
problems on the fly: instead of unlocking the door, maybe the player
could knock on it and get another character to open it - great! Except
that now the player hasn't had to obtain the key from the Very High
Shelf and so may not have the Extensible Gripper which is the only
*guaranteed* way to be able to later plant the Incriminating Matchbook
in the Mayor's Overcoat. Suddenly the game may have become unsolvable,
and our experience is that this is a much bigger deal for players than
having 'sensible' actions disallowed because they're not 'the (forseen)
solution.'
My experience of using TADS is that I spend much more time rummaging in
the toolbox to find exactly the right pre-made objects to hook together,
whereas writing in Inform 6 was much more a case of choosing a class,
maybe setting a couple of flags and then immediately getting down to
writing the text, replaying and tweaking it until it read right. (I've
not reached the same level of facility with I7 as yet; I'm still writing
trivial test stuff.)
For me the allure of TADS3 is not the world model with its sense passing
and sophisticated management of space, but its built in conversation
system. Stories are about people and the objects that represent NPCs are
the most complicated bits of code in any IF project, so here built-in
library support is exactly what I need. The I7 team have said elsewhere
on this newsgroup that they're deliberately holding back from this, not
wanting to stifle innovation by promoting the One True Conversation System.
I hope I've managed to explain why I think neither TADS nor Inform is
'better', but rather about finding the system which suits you best.
jz
Jeff Nyman
news:45d30eb3$1...@news.kcl.ac.uk...
> Secondly I'd point out that other forms of entertainment display the
> boundaries of the fictional world without it being considered a problem -
> if you glance up from the page, you're back in Mundania; if you talk to
> the characters on the screen, they don't reply to you - yet people enjoy
> books and TV shows nonetheless. Understanding that the cutlery on the
> tables in a restaurant scene is just 'moulded on' and can't really be used
> doesn't necessarily detract from enjoying a story any more than a seat on
> the left or right hand side of an auditorium which makes obvious the false
> perspective in the stage set.
I wholeheartedly agree with this. I'm not one of those that feels games have
to somehow simulate the "real world" or never allow for the "game mehanics"
to show through or the never allow "mimesis" to be broken. So to the extent
that some system takes care of all these details: I'm not really concerned.
It's a game. People know they're playing a game. People (well, hopefully
most people) know that games aren't the real world.
What I hope I can do is present a compelling story. Compelling enough that
obvious things (like the fact that you're playing a game) really don't
matter all that much because you had enough fun along the way.
> My experience of using TADS is that I spend much more time rummaging in
> the toolbox to find exactly the right pre-made objects to hook together,
> whereas writing in Inform 6 was much more a case of choosing a class,
> maybe setting a couple of flags and then immediately getting down to
> writing the text, replaying and tweaking it until it read right. (I've not
> reached the same level of facility with I7 as yet; I'm still writing
> trivial test stuff.)
Yeah, as I think on it, I can sort of agree with this, to an extent. One
thing I suppose I like about Inform 7 is that I just sort of .... start. I
don't sit there and plan out all these pre-steps, and getting my structures
in place, and so forth. I can just sort of iteratively build. I can do that
with TADS 3, of course, but I do find the process slightly more natural or
accomodating with Inform 7.
> I hope I've managed to explain why I think neither TADS nor Inform is
> 'better', but rather about finding the system which suits you best.
Something I've long asserted as well and agree with completely. You have to
choose the system that works with your style and what you like. It doesn't
always matter if it's (perceived as) the most "powerful." Some of the most
effective languages that people become loyal to are the ones that help them
program in the way that they think. This argument has long been used by
proponents of languages like Ruby and Python, as just two examples. I can
see this being one of the major "selling points" of a system like Inform 7
(regardless of all these virtual machine considerations or whatever else
people worry about).
- Jeff
Eric Eve
news:5Mmdnd1Yo9fljE7Y...@comcast.com...
> Something I've long asserted as well and agree with completely.
> You have to choose the system that works with your style and what
> you like. It doesn't always matter if it's (perceived as) the most
> "powerful."
Yes indeed. Or to put it another the most functionally useful
definition of "most powerful" in this context is "whichever system
you find it easiest to do what you want to do", and which that is
will depend on a number of factors including what you're used to,
how you like to work, and what it is you want to do. I can certainly
envisage the same author wanting to write one sort of game in TADS 3
and another sort of game in Inform 7, for example (as I did, say,
with Elysium Enigma and Dreadwine last year).
Blank wrote:
> For me the allure of TADS3 is not the world model with its sense
> passing and sophisticated management of space, but its built in
> conversation system. Stories are about people and the objects that
> represent NPCs are the most complicated bits of code in any IF
> project, so here built-in library support is exactly what I need.
> The I7 team have said elsewhere on this newsgroup that they're
> deliberately holding back from this, not wanting to stifle
> innovation by promoting the One True Conversation System.
I'd largely agree with this as well, to the extent that for me, too,
the conversation system built into the TADS 3 library is its biggest
single advantage so far as I'm concerned, though there are many,
many other features I also like about TADS 3. As I tried to indicate
in my recent SPAG interview, I think there's a danger that focusing
too much on the world model (in the sense of sense passing,
sophisticated management of space, and the rich selection of library
classes used for modelling the physical world) risks missing a lot
of the subtler differences between TADS 3 and I7 that may actually
have more bearing on how they feel to an author. As I've mentioned
elsewhere, when I made an I7 port of the opening of All Hope Abandon
the differences between the physical world models of the two systems
turned out to be much less of an issue than one might have expected
(given that there were one or two aspects of the TADS 3 world model
that I didn't bother to try to replicate in I7). For me it's not so
much the physical world models as the very different languages that
give TADS 3 and I7 that give the two systems a very different feel
from an author's perspective (and there's a sense in which, perhaps
because I'm more used to it, the TADS 3 language actually feels the
simpler of the two to me, in that it feels as if there are fewer
fundamental concepts to grasp, or at least that I have a securer
grasp of them).
I have attempted to write an Inform 7 extension that replicates some
of this functionality, but I'm frankly not very happy with it.
Perhaps one day I'll revisit it and see if I can come with something
a bit better. I keep feeling that with all the clever features I7
has there has to be a neat way of doing sophisticated conversation
systems that I'm just not seeing (but I don't have time to look into
it any further right now), but then I just haven't worked with I7
enough to the get the feel of it in the way that I've now got the
feel of TADS 3.
A final reason why comparisons (of the sort "X is more powerful than
Y") between I7 and TADS 3 are likely to misleading at this point is
that they are at rather different stages at development. TADS 3 has
matured into a release version after several years of development,
testing, and beta releases, which I7 has not yet been out in beta
for a single year yet, and is still undergoing significant
developments. A lot of areas in which one might feel tempted to say
"ah, but here TADS 3 is more powerful than I7" become overtaken by
new I7 releases where some perceived gap (e.g. in handling
disambiguation, to give a relatively recent example) is
satisfactorially addressed. I imagine that by the time I7 matures
into a (post-beta) release version, most of the significant
usability issues will have been addressed, and the choice between I7
and TADS 3 will be even more one of "What do I want to do in this
particular project, which tool best suits by goals and my working
methods, and which of the two do I happen to feel more comfortable
with?"
-- Eric
Blank
>gawd, I'd be done by now if I'd done it the easy way --
I should have that printed on a T-shirt!
Blank
rather than "buck passing" what you get is three different groups/people
simultaneously saying "bugger" and digging through the code.
Blank
> "Poster" <poster!nospam!@aurora.cotse.net> wrote in message
> news:9d2dnczs2pYyQlDY...@giganews.com...
>> Eric wrote:
>>> Okay, so with all this I've got the following information:
>>>
>>> It all comes down to how you prefer to write IF because the systems are
>>> largely the same, at least in terms of overall capabilities. If TADS 3
>>> seems more powerful that's just because of the up-front work done on the
>>> library, which is more complex. Inform 7 is just as complex but it
>>> doesn't appear that way because it's not written that way.
>>>
>>> In any event, T3 vs. z-machine vs. g-machine isn't really an issue at
>>> all.
>>>
>>>
>>>
>> This whole thread is hilarious because you begin by complaining that I7 is
>> too hard for newbies, and then you immediately launch into esoteric
>> discussions of Inform's virtual machine.
>>
>> Non-sequitur?
>>
>> -- Poster
>>
>> www.intaligo.com Building, INFORM, Seasons (upcoming!)
>
> What I said was that I kept hearing it was designed for beginners and I
> don't feel that's the case. And did you notice how you have to keep track of
> whether you're compiling to glulx or which z-machine version? Did you notice
> the oddities you have to sometimes do to get something to work on both? So,
> you know what, that does sort of get into the VM, doesn't it? Or to a
> beginner anyway, you're not sure how much of the VM matters.
>
>
I think it's fair to say that I7 is intended for beginners* but is still
in the process of being designed.
* - but not solely for beginners
steve....@gmail.com
> The driving assumption behind TADS is that the best way to provide a
> good game playing experience for the player is to simulate the 'real
> world'
Certainly not. The intrinsic value of realistic default response might
be "an" assumption, but it's certainly not a driving one, and most
certainly not "the driving assumption." And I don't see it's less of
an assumption in Inform. If you asked IF fans which games were most
"realistic," or "simulationist," or which games had the most robust
"world model," I think you'd hear a lot about a few games written in
Inform. (If you asked players what the main difference was between
TADS and Inform, they'd probably say that Inform reminded them more of
the tongue-in-cheek style of Infocom games. Yes, I would say that from
an audience point of view, the major difference is in the tone of the
default messages, and the kind of writing those default messages
inspire in the authors.)
So realism is no less an assumption in Inform, it's just that Inform
does less of the work, whereas in TADS-3, most of the work is done for
you. But that's just one of several examples where Inform does less
work, and TADS-3 does more. Conversations, as mentioned upthread, is
another example. The parser is much more malleable in TADS-3; the
event scheduler is more open; output formatting, multimedia, banners,
a lot more built-in and supporting extensions, etc.
I don't think TADS-3 is any harder to learn, it just doesn't act like
it's easier to learn than it actually is. But TADS-3 does so much more
for the user it's almost silly to compare the two. I7 is fine at doing
very conventional IF, cheers. But hey, that's what TADS-3 is
specifically geared towards also. You wouldn't want to pick I7 just
because you're doing very conventional IF.
> Inform, by contrast, works with a very stripped-down world model.
No, it works with the same conceptual world model, but I7 leaves most
of the custom work to the user. Whereas TADS-3 provides a lot of the
infrastructure, so the user needs to do relatively little custom work.
> chairs, thrones and balconies are all the same thing to Inform - they're
> supporters. It's up to the author to provide the text which
> distinguishes one from the other in the game world.
> Now it may seem at first glance that the TADS approach is obviously
> superior - surely every time the player becomes aware of gameworld
> mechanics, that's some kind of failure?
While I agree with the first statement, I don't see how the second is
related. Surely the player is almost immediately aware of the
gameworld mechanics, and the joy of playing the game has a lot to do
with the exploration of that mechanics.
> Secondly I'd point out that other forms of entertainment display the
> boundaries of the fictional world without it being considered a problem
Again, I don't imagine that players get the sense that TADS-3 games
are in any way more realistic or in any way less bounded. The fact
that TADS-3 provides a suite of tools for the design of a world model
does not mean that the user actually programs a robust world. Normally
they don't. It seems to happen more often that an ambitious writer
does the same thing in Inform from scratch, which could have been done
with far greater ease in TADS-3. Indeed, that's the motivating
assumption of any sort of library design -- that we want to save
people the trouble of writing the same code over and over.
steve....@gmail.com
> [T]the most functionally useful
> definition of "most powerful" in this context is "whichever system
> you find it easiest to do what you want to do"
I really hope that's not true. I think this is essentially a
restatement of "different tools are good for different jobs" -- which
is all well and good, both correct and polite, but obviously a
rudimentary proposition -- and I certainly hope it's not the limit of
what we can usefully say on the subject.
Consider the concept of "general" programming power: it's measurable;
some languages are highly celebrated, and some are not so hot. It has
a clear and objective meaning: general programming power is the
likelihood that any given programming task can be reasonably easily
accomplished in the language, by a competent programmer.
Reconsider the concept of "domain specific" programming power: it's
even more measurable. Where we doubt this, it's because we're confused
what exactly is the domain.
Indeed, what is the IF domain, and what is its future? I maintain its
future is AI, so general programming power is of utmost importance.
Others seem to believe that more prose is the way forward, and the
less programmy programming the better.
Eric Eve
news:1171507360.2...@v33g2000cwv.googlegroups.com...
> Eric Eve writes:
>
>> [T]the most functionally useful
>> definition of "most powerful" in this context is "whichever
>> system
>> you find it easiest to do what you want to do"
>
> I really hope that's not true. I think this is essentially a
> restatement of "different tools are good for different jobs" --
> which
> is all well and good, both correct and polite, but obviously a
> rudimentary proposition -- and I certainly hope it's not the limit
> of
> what we can usefully say on the subject.
My assumption was that in practice, most people asking/talking about
"which is the most powerful IF system" are in fact discussing the
purely practical question of which system is "best" to use, in which
case my definition stands (however mundane and rudimentary it may
be). Of course it's not the limit of what we can usefully say on the
subject once the context of discussion shifts to some other concern
(such as a more theoretical one).
> Consider the concept of "general" programming power: it's
measurable;
> some languages are highly celebrated, and some are not so hot. It
> has
> a clear and objective meaning: general programming power is the
> likelihood that any given programming task can be reasonably
> easily
> accomplished in the language, by a competent programmer.
It's measurable if we're sufficiently sure that we're comparing like
with like; that was the point of my example of comparing TADS 3 with
TADS 2 elsewhere in this thread, to illustrate how an objective
comparison might be made.
> Reconsider the concept of "domain specific" programming power:
> it's
> even more measurable. Where we doubt this, it's because we're
> confused
> what exactly is the domain.
Or because it becomes harder to make objective comparisons between
systems that take radically different approaches. At the very least
one needs first to define what criteria are being used to make the
comparison. One then needs to ensure that these criteria don't rig
the result of the comparison in way that undermines its alleged
objectivity. I don't deny that either task is possible, but it may
not be transparently obvious how to achieve it. That was in part the
point of my giving a sample comparison of TADS 3 and TADS 2, where
these tasks are more straightforward and thus might be used as
pointers for how to carry out comparisons in more difficult cases
(if they turn out to exemplify criteria that be generalized).
But one then still has to ask, what is the *point* of carrying out
such a theoretical comparison once we move beyond the mundane,
practical question of "which system should I use?" One point may be
to guide future developments, but then it would probably be useful
to clarify that this is the point we have in mind.
> Indeed, what is the IF domain, and what is its future? I maintain
> its
> future is AI, so general programming power is of utmost
> importance.
> Others seem to believe that more prose is the way forward, and the
> less programmy programming the better.
Yes, I'm not so sure I agree with you about the future of IF. It
seems to me that an AI approach presupposes a more simulationist
vision of IF (unless you're envisaging a very sophisticated AI
indeed), whereas I think I tend to be of the camp that's more
interested in exploring the narrative potential of IF (which seems
to me to be unlikely to be well served by incremental improvements
in AI from where we are now).
-- Eric
steve....@gmail.com
> > Eric Eve writes:
>
> >> [T]the most functionally useful
> >> definition of "most powerful" in this context is "whichever
>
> > I certainly hope it's not the limit of
> > what we can usefully say on the subject.
>
> My assumption was that in practice, most people asking/talking about
> "which is the most powerful IF system" are in fact discussing the
> purely practical question of which system is "best" to use, in which
Even so, it's a worthwhile question, worth answering with more than
the word "depends." "Depends" is probably a worthwhile caveat, but it
begs the question, "depends on what?" Could we start working out what
it depends on?
> > [G]eneral programming power is the likelihood that any
> > given programming task can be reasonably easily
> > accomplished in the language, by a competent programmer.
>
> It's measurable if we're sufficiently sure that we're comparing like
> with like[...] It becomes harder to make objective comparisons
> between systems that take radically different approaches.
I don't think that's true. I mean, yes it requires more thought to
make a reasonable comparison if we're dealing with a more complicated
situation than "X is more powerful than Y because Y is a subset of X."
-- But comparing C++ to BASIC is still pretty obvious.
> At the very least
> one needs first to define what criteria are being used to make the
> comparison.
Ah, that's a great idea. Maybe someone sufficiently familiar with both
languages will be able to suggest a criteria. Maybe a quick look
through the source for a few games written in each language will
identify a sufficient number of common patterns, and we can consider
these patterns in abstract and move the analysis from there.
> But one then still has to ask, what is the *point* of carrying out
> such a theoretical comparison once we move beyond the mundane,
> practical question of "which system should I use?"
Bear in mind, mine isn't some "theoretical" interest, but will help
advance the answer to that "practical question" you pose.
Conrad
> On 2007-02-09, Eric <-> wrote:
>
> > Okay, but *could* the Inform 6 library be as powerful as the
> > TADS 3 library if someone built it up?
>
> from. Platypus is one, and I can't remember what the other one
> is.
Can anybody tell me where I can find these?
Conrad.
ps - My 2 cents --
So far, the natural-language-like nature of i7 is interfering with my
ability to grok the nature of the language: its syntax, how it orders
execution, etc. It seems to be an inference engine; true? In other
words, the quasi-English cloaks exactly what I need to learn.
Seems to be a nice system; I'd just rather have alien terminology for
alien logic.
C.
Emily Short
> On Feb 9, 1:34 pm, Neil Cerutti <horp...@yahoo.com> wrote:
>
> > On 2007-02-09, Eric <-> wrote:
>
> > > Okay, but *could* the Inform 6 library be as powerful as the
> > > TADS 3 library if someone built it up?
>
> > Yes. There are even two(?) 3rd-party Inform libraries to choose
> > from. Platypus is one, and I can't remember what the other one
> > is.
More than that, really, though there are three for general standard
use:
-- Platypus, which has been used successfully by a few authors
(notably A O Muniz in "A New Life") but is currently unsupported and
has some bugs;
-- Triform, about which I know almost nothing but which is more
recent;
-- the Onyx Ring library set, which is designed so that some modules
can be incorporated piecemeal, but which does offer fairly massive
replacements of parsing and output code if you go for the whole
system.
The other two are more special-purpose:
-- Minform, a rewrite of the library for a minimal footprint and very
very small story files;
-- Real Time, which works on real-time input.
I don't think any of these quite approaches the sophistication of the
current TADS 3 library, though my impression is that the Onyx Ring set
may come closest in some respects.
> Can anybody tell me where I can find these?
They're all linked from
http://www.inform-fiction.org/extensions/replacements.html
> ps - My 2 cents --
>
> So far, the natural-language-like nature of i7 is interfering with my
> ability to grok the nature of the language: its syntax, how it orders
> execution, etc. It seems to be an inference engine; true? In other
> words, the quasi-English cloaks exactly what I need to learn.
This doesn't address the whole substance of your complaint, but, for
what it's worth, many order-of-execution questions are addressed in
the Laws chapter in the Rulebook.
steve....@gmail.com
> > So far, the natural-language-like nature of i7 is interfering with my
> > ability to grok the nature of the language: its syntax, how it orders
> > execution, etc. It seems to be an inference engine; true? In other
> > words, the quasi-English cloaks exactly what I need to learn.
>
> This doesn't address the whole substance of your complaint, but, for
> what it's worth, many order-of-execution questions are addressed in
> the Laws chapter in the Rulebook.
Interesting choice of words. First, Conrad isn't "complaining" -- it's
a perfectly valid criticism. But even more Shortian: you admit that
you're not addressing "the whole substance" of the criticism, but that
implies that you're addressing some fraction of the substance -- when
in fact you're not addressing the criticism whatsoever.
The point here is *not* that I7 doesn't have a symbolic order (of
course it does), *nor* that this isn't documented somewhere (although
the I7 manual is pretty bad about hiding the symbolic order in an
attempt to conceal that there is one, which is a separate criticism).
The criticism has to do with the "natural-language-like nature of I7":
that it "cloaks" what we want to know: the logical structure of the
language, e.g., the syntax, the execution order, etc.
Essentially, a formal symbolism self-documents, emphasizes, in bold
relief, its logical structure -- whereas I7 cloaks it.
It reminds me of an old Twilight Zone episode, where the person wakes
up and everyone they know has suddenly started talking in an alien
language. But that's not the scary part -- after all, one could always
learn a new language. The scary part is that the new language is
composed of words from the old language, but horribly misarranged.
(For example, 'red' now means 'soft.') I guess the reason this is so
scary is that it's much harder and upsetting and unsettling to re-
learn something differently, than it is to learn something new. To
learn the new language our protagonist must in effect erase her old
language.
Conrad
>
> Interesting choice of words. First,Conradisn't "complaining" -- it's
> a perfectly valid criticism. But even more Shortian: you admit that
> you're not addressing "the whole substance" of the criticism, but that
> implies that you're addressing some fraction of the substance -- when
> in fact you're not addressing the criticism whatsoever.
I would say I was neither complaining, nor criticising, but bitching.
> The point here is *not* that I7 doesn't have a symbolic order (of
> course it does), *nor* that this isn't documented somewhere (although
> the I7 manual is pretty bad about hiding the symbolic order in an
> attempt to conceal that there is one, which is a separate criticism).
My point, which I'm thinking is different from yours in ways you'll
see, is that, having a basic competency in various matters technogeek,
I can generally pick up a programming language -- to, say, 70 or 80
percent -- by reading the language specs and flailing around with the
interpreter for a few hours. So Emily's short comment may be helpful
-- won't know until I look.
On the other hand, I've done a bit of hobbying with Prolog, and i7
seems like an inference engine to me. Which is interesting if true; a
thought I'll pursue once I've gotten a handle on the logic.
> Essentially, a formal symbolism self-documents, emphasizes, in bold
> relief, its logical structure -- whereas I7 cloaks it.
Yeah, that's what I'm getting at. From what I've seen, i7 looks like
a fine whirligig, and I don't mean to knock it. Not before I've
learned it. I'm just doing a little well-intended bitching, as is my
God-given right as an American citizen.
Seems to me from what's not being said there's some kinda tension
between you & Emily. Ugly break-up? Anyway, I'm not in that.
Conrad.
ps -
> It reminds me of an old Twilight Zone episode, where the person wakes
> up and everyone they know has suddenly started talking in an alien
> language. But that's not the scary part -- after all, one could always
Hey, I don't know that one. Do you remember the name?
C.
steve....@gmail.com
> I would say I was neither complaining, nor criticising, but bitching.
You may say so, but I wouldn't have. It's a legitimate criticism, and
I think a serious one.
> I can generally pick up a programming language -- to, say, 70 or 80
> percent -- by reading the language specs and flailing around with the
> interpreter for a few hours.
Typical languages sort-of document themselves, just by virtue of
expressing their formalism in the clearest way possible.
> On the other hand, I've done a bit of hobbying with Prolog, and i7
> seems like an inference engine to me. Which is interesting if true; a
> thought I'll pursue once I've gotten a handle on the logic.
It's a weird mix. It's certainly part inference engine.
> > It reminds me of an old Twilight Zone episode, where the person wakes
> > up and everyone they know has suddenly started talking in an alien
> > language. But that's not the scary part -- after all, one could always
>
> Hey, I don't know that one. Do you remember the name?
http://en.wikipedia.org/wiki/Wordplay_%28The_Twilight_Zone%29