My take on Inform 7
sasq
ago, and I had not read anything about it before hand.
I can only say that first reading about it, then downloading it and
trying it out, I felt like a small kid on christmas eve. Not only was
the new Natural Language syntax incredibly exciting, but the whole
product is polished and the documentation almost complete. And it
really works. It really does feel like a quantum leap in IF
development.
To all you who worked on this; It's an absolutely amazing
accomplishment. I think I finally have to put some time aside to try
and write something for real.
The only thing I currently miss is some sort of basic syntax-reference.
For instance, I found no place that explained clearly how begin / end
works, and that you could use semi-colon to continue blocks. Or a list
of basic actions rules etc and how they are usually written.
It would help if you could download the manual entirely in one
HTML-file so you could quickly browse and search for things.
(Also, small bug in the Mac version, using any shortcut in the
documentation window deactivates the window so you have to click once
before using Apple-Left, Apple-Right etc.)
Well, back to writing for me - I finally have some good use of that
iBook I bought a year ago :)
Again, it was a long time since I was this excited over a piece of
software...
-- Jonas Minnnerg
Krobar
sasq wrote:
> I joined the party late and only discovered the I7-release a few days
> ago, and I had not read anything about it before hand.
>
> I can only say that first reading about it, then downloading it and
> trying it out, I felt like a small kid on christmas eve.
I, too, just found I7 and am awestruck. WOW! For a beta project, I am
amazed at how complete it it. If I could suggest two things, it would
be to add the ability to use the arrow keys to scroll up/down and move
back/forward through the documentation or whatever screen had focus.
I'd also like to see some say to open "published" games and play them
within the I7 application with the ability to have it map out the world
(as well as the other index functions) as you play and save a tanscript
of your play to date. I7 would then become not only the ultimate
programming platform, but the ultimate playing one as well.
D.
steve....@gmail.com
sasq wrote:
> I joined the party late and only discovered the I7-release a few days
> ago, and I had not read anything about it before hand.
>
> I can only say that first reading about it, then downloading it and
> trying it out, I felt like a small kid on christmas eve. Not only was
> the new Natural Language syntax incredibly exciting, but the whole
> product is polished and the documentation almost complete.
> The only thing I currently miss is some sort of basic syntax-reference.
I'd be interested in hearing more how well the excitement carries, once
the "christmas kid" effect wears off, and the NL-syntax becomes more
familiar as a syntax (as opposed to, say, telling the computer in
"layman's terms" what you want it to do, which is how I think it's
designed to present itself).
Everyone misses a basic syntax-reference. I think there's three reasons
that there's no basic syntax-reference: 1) it's beta, and syntax isn't
finished; 2) the designer doesn't want to emphasize the fact that there
is a programming syntax, because he wants to pretend that it's NL; 3)
you can't write a programming syntax for NL, and the designer hasn't
decided where (or how) to draw the line.
> For instance, I found no place that explained clearly how begin / end
> works, and that you could use semi-colon to continue blocks.
That should be documented. That lacuna would fall under #2. The
designer doesn't want to emphasize that it's code-blocks. Last I heard,
he's still pretending it's paragraphs.
John Prevost
> Everyone misses a basic syntax-reference. I think there's three reasons
> that there's no basic syntax-reference: 1) it's beta, and syntax isn't
> finished; 2) the designer doesn't want to emphasize the fact that there
> is a programming syntax, because he wants to pretend that it's NL; 3)
> you can't write a programming syntax for NL, and the designer hasn't
> decided where (or how) to draw the line.
I don't think it's that simple, either. A general reference would be
good, but at the same time there are a lot of places where the syntax
is extensible, and where meanings can be changed. For example:
X is Y.
The above predicate is one of the simplest things you can say, but can
mean a couple of different things depending on context:
{Z - the last object mentioned.} (X - the name of an existing property)
is (Y - a value). => X(Z) = Y.
(X - the name of something that hasn't been seen before) is (Y - the
name of a kind). => X is an object. kind(X) = Y.
And additionally, if you try to use the name of a property for the name
of an object, you'll get an error.
And, of course, if you say something more complicated, like "X is a
kind of K.", the complexity multiplies. And, of course, the names of
things can be confusing.
As an example of how the definition of things can change meanings, look
at this example:
Bob is a room. Pointless is north of bob.
After waiting: if in pointless, say "pointless".
In the above code, "pointless" is printed if you wait in the room named
"pointless." But if you add the following definition between those two
lines:
To decide whether in pointless: decide yes.
Now the definition of "in pointless" overrides the normal definition of
"in".
Actually, I think the thing I would *really* like is not for all of
these kind of utterances that are alive by default to be listed in the
documentation, but for the compiler to output all of them into the
index, in a way that makes it easy to find them. The original decision
above is defined in the standard rules:
To decide whether in (somewhere - an object):
(- (I7_WhetherIn({somewhere})) -).
In the index, this is sorted under "Moving and Removing Things" in the
phrasebook (although I actually had to look really hard before I found
it--for a while I didn't think it was there):
if in (the name of something) ...
It doesn't have a link or a definition, however.
The "in pointless" decision is then listed down below, under "defined
in the source".
More disturbing are the things that really aren't in the index. If I
change the above "After..." rules to:
After waiting, if the player is in pointless, say "pointless".
Now, the rule triggers again only when the player is in that room.
(The "in pointless" decision doesn't happen, because there's an
argument first. Again, we can override this:
To decide whether (X - an object) is in pointless: decide yes.
HOWEVER, there is no definition in the Standard Rules for "To decide
whether (X - an object) is in (Y - an object)". And there's no listing
of this in the index, either.
What I'd suggest:
1) Everything should be in the phrasebook. "X is in Y" is obviously
some sort of primitive. It's fairly obvious what it should mean, but
since it can be overridden at times to mean other things, it would be
better for it to be better documented.
2) There needs to be an easier way to find things in the index.
Perhaps there need to be multiple orderings. One thing I typically
want to know is "what are all of the things I can say about a room?",
which implies perhaps a list of all phrases based on argument types.
Another interesting thing to ask the compiler would be: "If I say 'blah
the blah', what definition applies?", likewise for "If I ask if 'the
player is in pointless', what definition applies?"
3) A quick reference, probably also in the index, perhaps in the
documentation as well, for the "special" syntax of loops and long
conditionals, and general grammar rules like X; Y.
I will say, though, that the whole system is pretty impressive,
especially for something that is so incredibly flexible. It's just
that when the meaning of whole phrases can be redefined by pattern
matching in so many powerful ways, it's important to be able to ask
what you can say, or what what you've said means.
John.
Andrew Plotkin
>
> 1) Everything should be in the phrasebook. "X is in Y" is obviously
> some sort of primitive. It's fairly obvious what it should mean, but
> since it can be overridden at times to mean other things, it would be
> better for it to be better documented.
Hm. This line is in the phrasebook (under "Moving and Removing Things"):
if in (the name of something) ...
But this is neither easy to find nor easy to compare to other phrases,
like your sample
if (the name of something) is in pointless ...
So your point about finding entries stands.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
"Bush has kept America safe from terrorism since 9/11." Too bad his
job was to keep America safe *on* 9/11.
John Prevost
Andrew Plotkin wrote:
> Here, John Prevost <j.pr...@gmail.com> wrote:
> >
> > 1) Everything should be in the phrasebook. "X is in Y" is obviously
> > some sort of primitive. It's fairly obvious what it should mean, but
> > since it can be overridden at times to mean other things, it would be
> > better for it to be better documented.
>
> Hm. This line is in the phrasebook (under "Moving and Removing Things"):
>
> if in (the name of something) ...
Right--I found that one, after a bit of looking, as I remarked.
However, "(the name of something) is in (the name of something)" isn't
in the phrasebook. That is: the phrasebook contains the rule for the
shorthand form of "is the player in X?", but there's no listing for the
more general question "is thing X in thing Y?". (And actually, they're
not quite the same: If the player's in a container, "in X" is true if
the container is in X, but "the player is in X" is false.
I suspected that this might be because "X is in Y" is a world-building
construct, and perhaps those constructs are special cased to
automatically be phrases. But other world-building constructs don't
seem to be allowed. (For example: "X is north of Y", for rooms, but
not "if X is north of Y".) Another possibility is that this is
sort-of-documented in the form of the verb "contains", as it looks like
"X is in Y" may be the same as "X is container by Y" which is the same
as "Y contains X".
So there are at least some decisions that are "primitive" and don't get
put in the index (like "X is in Y"). The base "assertions" that you
can use to build the world are also not documented in the index, as far
as I know (though these are much less extensible.)
And there are the places where things are documented, but not quite as
well as I'd like. For example:
------------------------------------------------------------------------
"If in Y vs. If the player is in Y test" by John Prevost
Bob is a room.
Zimbabwe is a thing. Zimbabwe is enterable. Zimbabwe is in Bob.
After waiting: if the player is in Zimbabwe, say "Aha!"
Instead of jumping: if in Zimbabwe, say "Oh boy!"
test me with "wait / enter zimbabwe / wait / out / jump".
------------------------------------------------------------------------
Anyway, I am starting to get the hang of things, and I am trying to
make a list of these oddities when I find them, so that I can later
supply a list of what I believe to be erroneous (or poorly documented)
phrases as one big possible-bug report.
John.
Andrew Plotkin
>
> Andrew Plotkin wrote:
> > Here, John Prevost <j.pr...@gmail.com> wrote:
> > >
> > > 1) Everything should be in the phrasebook. "X is in Y" is obviously
> > > some sort of primitive. It's fairly obvious what it should mean, but
> > > since it can be overridden at times to mean other things, it would be
> > > better for it to be better documented.
> >
> > Hm. This line is in the phrasebook (under "Moving and Removing Things"):
> >
> > if in (the name of something) ...
>
> Right--I found that one, after a bit of looking, as I remarked.
> However, "(the name of something) is in (the name of something)" isn't
> in the phrasebook.
Right, my mistake. Those are different phrases.
> I suspected that this might be because "X is in Y" is a world-building
> construct, and perhaps those constructs are special cased to
> automatically be phrases.
It's a relation, and I think all relations are supposed to be valid
conditions.
> But other world-building constructs don't
> seem to be allowed. (For example: "X is north of Y", for rooms, but
> not "if X is north of Y".)
This surprises me. You can say "if X can see Y", "if X is part of Y",
and the other built-in relations. So it may be a specific problem with
the map relations. "If the north exit of R1 is R2" also fails.
Oh, you can say "if the room north from R1 is R2..." However, "The
room north from R1 is R2." is not a valid top-level assertion. So this
is a mismatch between how the map relations are declared and tested,
which is worth a bug report; but other kinds of relations (including
player-declared ones) seem to be conditions automatically.
The point is, "if" statements depend on conditions, not phrases. A "to
decide whether..." phrase is a way to define a new condition.
Relations are another way.
(So maybe there should be a table of *relations* somewhere in the
index.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a
warrant, it's for one reason: they don't feel like it. Not because of
the Fourth Amendment.
John Prevost
> The point is, "if" statements depend on conditions, not phrases. A "to
> decide whether..." phrase is a way to define a new condition.
> Relations are another way.
>
> (So maybe there should be a table of *relations* somewhere in the
> index.)
Aha. You have indeed identified the main variety of condition that
isn't listed in the index, and the one that was giving me trouble. I
see that in the manual, this is where the containment concept is
addressed, and where the syntax "X is in Y" is addressed.
And, in fact, when I define my own version of this, the documentation
has the same deficits as for the built-in containment relation.
The three problems I note are:
1) Verbs are listed, along with their conjugations. However, the
relations they represent are not. In most normal situations, this
isn't a problem, because the verb and the name of the relation should
be consistent with each other. However, it's possible that the
designer of a system would use multiple verbs for the same relation.
(Although, since verbs don't seem to be overridden when re-defined, nor
overloadable by the kind of argument, polluting the namespace with many
synonyms might be a bad idea.)
2) More importantly, verbs that represent conditional relations
(section 12.13 of the manual in Windows version 3R85) of course don't
mention the condition, either, since that's part of the relation.
3) And finally, prepositions are not listed at all--and this is where
"in" would show up ("to be in"). This is true of both the built-in
prepositions and those defined in the source text.
In any case, thank you very much for helping me work through this. I'm
going to go put in a bug report now, as I think this pretty much takes
care of my main issue. There's still the matter of making it easier to
find things in the index, but having everything included is a very good
start.
John.
Seebs
sasq <sas...@gmail.com> wrote:
>I can only say that first reading about it, then downloading it and
>trying it out, I felt like a small kid on christmas eve. Not only was
>the new Natural Language syntax incredibly exciting, but the whole
>product is polished and the documentation almost complete. And it
>really works. It really does feel like a quantum leap in IF
>development.
Okay, I'm not getting it.
I have never in my life wanted "natural language programming".
I can see how it might appeal to people who don't habitually pick up new
programming languages. But... Given that I already know Inform6, is there
any reason at all to switch to Inform7? Is there something it will do for
me that I want done? Does it offer more flexibility in coding? I mean, I
saw someone talking about "a way to implement a switch". I use switches a
fair bit; if anything, it sounds like this makes things harder.
It's interesting, and it's neat to open the genre to new writers, but...
Here I sit, with a command line and a bunch of .inf files. Do I have any
reason to download the new stuff? Will it even run on my non-Windows, non-Mac
system?
-s
--
Copyright 2005, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
Andrew Plotkin
> In article <1151657460.9...@y41g2000cwy.googlegroups.com>,
> sasq <sas...@gmail.com> wrote:
> >I can only say that first reading about it, then downloading it and
> >trying it out, I felt like a small kid on christmas eve. Not only was
> >the new Natural Language syntax incredibly exciting, but the whole
> >product is polished and the documentation almost complete. And it
> >really works. It really does feel like a quantum leap in IF
> >development.
>
> Okay, I'm not getting it.
>
> I have never in my life wanted "natural language programming".
There were a lot of posts back in May (including some from Emily and
some from me) on what I7 brings that is new. Natural language is one
of (in my estimation) three major conceptual leaps.
(I don't say three major *improvements* -- if you don't want NL, you
don't want it. But they are leaps.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Just because you vote for the Republicans, doesn't mean they let you be one.
Seebs
Andrew Plotkin <erky...@eblong.com> wrote:
>There were a lot of posts back in May (including some from Emily and
>some from me) on what I7 brings that is new. Natural language is one
>of (in my estimation) three major conceptual leaps.
Okay.
>(I don't say three major *improvements* -- if you don't want NL, you
>don't want it. But they are leaps.)
Fair enough. :)
Mostly, I'm coming to this as someone who's been too busy to do IF for a
while.
I don't use Windows or a Mac. Is any of the new stuff even accessible to
me?
steve....@gmail.com
> Natural language is one
> of (in my estimation) three major conceptual leaps.
>
> (I don't say three major *improvements* -- if you don't want NL, you
> don't want it. But they are leaps.)
Leaps? Ok. Maybe you say lateral leaps, but even so.
1) The "NL" syntax is, I suppose, a lateral leap, but until it realizes
itself, it's really a conceptual leap to call it other than a stumbling
pretense. NL-like language can be a useful programming syntax, but only
if it explicitly thematizes itself as a programming syntax.
Context-sensitive syntax does not qualify as a programming leap, any
more than poop-flavored ice-cream qualifies as a culinary leap. I mean,
if you want to call it that, okay I guess....
2) Rule-orientation is not a new leap: AIFT does it more
thoroughgoingly. -- not that I think this is important. There was no
problem to solve. OO is fine, conflicts are *rare* and even so, they
are *easily resolved* within an OO framework. Rule-orientation is a
solution in search of a problem. (I challenge you to give a single
"common" conflict-situation which is difficult to code in TADS 3.)
Also, a lot of OO structures, and quite a bit of TADS 3, is rule-based.
-- More in the sense that it's largely declarative (but procedural as
needed), which I have a strong personal preference for.
3) What's the third? You mentioned three major "leaps"....
Andrew Plotkin
>
> Mostly, I'm coming to this as someone who's been too busy to do IF for a
> while.
Sure -- you missed the initial flurry of discussion, is all.
> I don't use Windows or a Mac. Is any of the new stuff even accessible to
> me?
This was in the initial flurry, too, but I wasn't paying much
attention because I have a Mac.
There is no official Unix/Linux support yet. There's a GTK IDE in
progress at <http://thewhitelion.org/inform7>. (Hm. I can't reach that
server right now.) You need will also need WINE to run part of the
compiler (only available as a Mac or Windows binary).
The Unix support will become official at some point, and all the
compiler components will come out in source-code form. (We don't know
when, but progress is being made on both these fronts.) So if you
don't want to mess with WINE, you may have to wait a while anyway.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
You don't become a tyranny by committing torture. If you plan for torture,
argue in favor of torture, set up legal justifications for torturing
someday, then the moral rot has *already* set in.
vaporware
[...]
> 1) The "NL" syntax is, I suppose, a lateral leap, but until it realizes
> itself, it's really a conceptual leap to call it other than a stumbling
> pretense. NL-like language can be a useful programming syntax, but only
> if it explicitly thematizes itself as a programming syntax.
> Context-sensitive syntax does not qualify as a programming leap, any
> more than poop-flavored ice-cream qualifies as a culinary leap. I mean,
> if you want to call it that, okay I guess....
>
> 2) Rule-orientation is not a new leap: AIFT does it more
> thoroughgoingly. -- not that I think this is important. There was no
> problem to solve. OO is fine, conflicts are *rare* and even so, they
> are *easily resolved* within an OO framework. Rule-orientation is a
> solution in search of a problem. (I challenge you to give a single
> "common" conflict-situation which is difficult to code in TADS 3.)
> Also, a lot of OO structures, and quite a bit of TADS 3, is rule-based.
> -- More in the sense that it's largely declarative (but procedural as
> needed), which I have a strong personal preference for.
Let the record show that Steve Breslin doesn't like rule-based
programming, except in systems other than Inform 7.
> 3) What's the third? You mentioned three major "leaps"....
The third is relations. There's built in support for tracking various
types of relationships between objects (one to one, one to many, many
to many, reciprocal or not) and tracing paths through them. This
basically eliminates the need to explicitly declare properties that
point to other objects.
Relations tie into the NL syntax by letting you refer to "every woman
who loves Romeo", etc., and you can also define code-driven relations,
so "X is near Y" is true when X and Y have the same location.
I can't wait to hear how unoriginal and worthless this feature is.
vw
Zonk the Troll Questioner
Hey Mr. Steve Breslin, I am curious: have you tried to implement
something of even medium complexity with I7? For someone who loves to
jump into I7 threads to comment on I7 in predictably negative ways, you
have also shown startling ignorance of any specific mechanics of I7
whenever your comments drift outside of theory.
Healthy discussion and criticism of I7's flaws and the ways they could
be improved has occurred on this group, but such fruitful discussion
comes from people who have actually USED I7, and therefore have
actually useful things to say about its strengths and weaknesses.
You, on the other hand, start from the (very thoroughly expressed by
now) premise that I7 is fundamentally flawed in its entire conception
and theoretical framework, and proceed from there to proclaim that it
cannot possibly have any real strengths, only apparent ones at best. It
is certainly your right to hold such a transparent "I know what this
thing is in essence without actually using it" position, but does it
really add to any discussion of I7 itself to endlessly repeat minor
variations of this position?
Take your comments above. Content-wise, they say nothing about I7,
they only express your by now well-known "Pseudo-NL is bad" and
"Object-oriented is better than rule-based" theoretical positions,
which you continually apply to I7 in an a priori manner.
I think the only imaginable parallel would be if someone were to
continually post condemnations of TADS 3, based on their theoretical
abhorrence of the T3 library's object-oriented design and overwhelming
size, in threads on the TAD 3 discussion list, while at the same time
never deigning to actually use T3.
- ZtTQ
steve....@gmail.com
> > 2) Rule-orientation is not a new leap: AIFT does it more
> > thoroughgoingly. -- not that I think this is important. There was no
> > problem to solve. OO is fine, conflicts are *rare* and even so, they
> > are *easily resolved* within an OO framework. Rule-orientation is a
> > solution in search of a problem. (I challenge you to give a single
> > "common" conflict-situation which is difficult to code in TADS 3.)
> > Also, a lot of OO structures, and quite a bit of TADS 3, is rule-based.
> > -- More in the sense that it's largely declarative (but procedural as
> > needed), which I have a strong personal preference for.
>
> Let the record show that Steve Breslin doesn't like rule-based
> programming, except in systems other than Inform 7.
That's not a very good summation of my point. I'm saying that calling
I7's rule-orientation a "leap" is wrong for a number of reasons.
First and most obviously, I7 is by no means the first rule-based system
for IF.
Second, there's rule-oriented programming in procedural languages like
TADS.
No, rule-orientation isn't a leap at this point.
But even if we pretend it *is* the first rule-oriented system for IF --
why should we call that a leap? This is the first time any
rule-oriented system has made this claim: it handles collisions between
object behaviors, which procedural programming can't manage. But that's
just plain incorrect.
If there is an I7 "leap" involving its rule-based orientation, then
it's got to be more particular than the mere fact that it involves
rules, or that it assumes a default behavior, effectively making you
specify (as always) in a different form what's the desired behavior
when rules conflict (note: it's impossible to avoid this specification
no matter the platform; it's only the *form* of the specification which
changes).
I suspect that this funny claim is really just the "brand name" effect.
(Like imagine Nike starts making flip-flops, and everybody starts
wearing them and remarking how splendid flip-flops are, what a perfect
solution to the problem, etc. -- and ultimately saying that flip-flops
are a "leap" in the development of footwear. Then hopefully someone
comes along and asks why the hell we're supposed to call flip-flops a
"leap" -- and the faithful floppers don't like this kind of remark, and
so respond with: "Let the record show that Steve Breslin does not like
flip-flops.")
vaporware
[...]
> That's not a very good summation of my point. I'm saying that calling
> I7's rule-orientation a "leap" is wrong for a number of reasons.
>
> First and most obviously, I7 is by no means the first rule-based system
> for IF.
It's the first popular one, and the first widely-accessible one.
> Second, there's rule-oriented programming in procedural languages like
> TADS.
Talk about stretching the meaning of the word.
> But even if we pretend it *is* the first rule-oriented system for IF --
> why should we call that a leap? This is the first time any
> rule-oriented system has made this claim: it handles collisions between
> object behaviors, which procedural programming can't manage. But that's
> just plain incorrect.
I7 isn't making that claim on its own. I7 *users* are making that claim
in an attempt to explain to you how I7 has made it easier for them to
write. Maybe if you'd put some effort into learning about the system
you criticize, they wouldn't have to make such claims.
> If there is an I7 "leap" involving its rule-based orientation, then
> it's got to be more particular than the mere fact that it involves
> rules, or that it assumes a default behavior, effectively making you
> specify (as always) in a different form what's the desired behavior
> when rules conflict (note: it's impossible to avoid this specification
> no matter the platform; it's only the *form* of the specification which
> changes).
You know, this reminds me of a story.
Once upon a time, there was a game called Quake, and it was probably
the first FPS where looking up and down was important, because unlike
games like Doom that came before it, Quake took place in a fully 3D
environment.
Now, you could still control Quake with the keyboard, just like you
were playing Doom. Walk and turn with the arrow keys, strafe with the
comma and period keys, fire with Ctrl, and if you needed to, look up
and down with the A and Z keys. Many Doom players kept using the same
control scheme they were used to, and why not? There were only a few
times in the single-player game where you really needed to look up or
down, and pausing for a moment to hit the A key didn't cause any
trouble.
There was a new control scheme also, called mouselook: you could put
one hand on the keyboard for walking, strafing, and jumping, and put
the other hand on the mouse for looking in all directions and firing.
Many players didn't use it because it was unfamiliar and a little
harder to control at first, and on paper, it didn't sound all that
useful: it didn't let you do anything you couldn't technically do with
the keyboard already.
But then there was online play, where you weren't just fighting dumb AI
enemies who were carefully placed by the level designers; you were
fighting human opponents who moved around, hid behind things, circled
around you, got up on ledges, and fired at you from every direction.
Keyboard players stood no chance against mouselook players, because the
situations where mouselook paid off, which sounded so hypothetical and
never really came up in the single player game, happened all the time
in multiplayer; the keyboard players were trying to move their
crosshair with Etch-A-Sketch controls while mouselook players moved it
with the ease of a pen. Even players like myself who were initially
hostile to mouselook soon made the switch and never looked back.
Steve, you are stuck in single player mode. No one is going to be able
to convince you that these new features are useful if you're unwilling
to do some hands-on learning. The posters here who consider I7 a big
step forward from what they've been using aren't deluded, or sucking up
to Graham - they've just *used* the damn thing with an open mind.
> I suspect that this funny claim is really just the "brand name" effect.
I'm sure that does have something to do with the popularity of I7, but
not all by itself. I7 is accessible to I6 authors because it's based
around the same library, uses many of the same terms and standard
behavior, and lets authors dig down into I6 code if they need to. But,
perhaps more importantly, *games* written in I7 are accessible to the
same people who've been playing IF for years now, because it compiles
to the very same VM.
> Then hopefully someone
> comes along and asks why the hell we're supposed to call flip-flops a
> "leap" -- and the faithful floppers don't like this kind of remark, and
> so respond with: "Let the record show that Steve Breslin does not like
> flip-flops.")
Ah, you've found me out. I'm nothing but a faithful Inform fanboy,
although I cleverly hid my true colors by not writing anything in
Inform for 8 years before I7 came out.
vw
Rifflesby
vaporware wrote:
> Once upon a time, there was a game called Quake, and it was probably
> the first FPS where looking up and down was important, because unlike
> games like Doom that came before it, Quake took place in a fully 3D
> environment.
> There was a new control scheme also, called mouselook: you could put
> one hand on the keyboard for walking, strafing, and jumping, and put
> the other hand on the mouse for looking in all directions and firing.
Hardly a leap -- Marathon did it first.
Just sayin'. ;)
steve....@gmail.com
> > [T]here's rule-oriented programming in procedural languages like
> > TADS.
>
> Talk about stretching the meaning of the word.
No, I don't think so. Take the conversation system of TADS 3. The
author wraps conversation snippets in objects, which are "active" or
"inactive" based on the current game state. These conversation objects
are effectively compiled into a database, which a core algorithm
consults when deciding the NPC's response to an interaction. To
consider these objects "rules" for conversation seems perfectly
correct. I would not think it odd if someone remarked that TADS 3
conversation is a rule-based subsystem.
> > But even if we pretend it *is* the first rule-oriented system for IF --
> > why should we call that a leap? This is the first time any
> > rule-oriented system has made this claim: it handles collisions between
> > object behaviors, which procedural programming can't manage. But that's
> > just plain incorrect.
>
> I7 isn't making that claim on its own. I7 *users* are making that claim
> in an attempt to explain to you how I7 has made it easier for them to
> write.
That people enjoy I7 is not a question -- both its users and its
designer. It's okay, people make inaccurate claims to justify their
love, when certain aspects of the system are put to question -- I
understand the emotional motivation of even the most ridiculous
responses, and the hostility against challenge neither bothers nor
surprises me. But it's also okay to point out when a claim is
inaccurate.
> Maybe if you'd put some effort into learning about the system
> you criticize, they wouldn't have to make such claims.
You're blaming me (on false grounds) for other people saying inaccurate
things. That's okay, but it makes it more difficult to have a rational
discussion.
> Steve, you are stuck in single player mode. No one is going to be able
> to convince you that these new features are useful if you're unwilling
> to do some hands-on learning.
I daresay that someone can use I7 and be unimpressed. That doesn't mean
they're backward-thinking. I have learned I7 well enough to ask certain
questions and make certain points. I don't think there's any legitimate
reason to suspect that I dislike I7 because I don't understand it, for
I have laid out a pretty full argument. Emotional accusations like this
are probably motivated by a lack of willingness to accept that my
points do hold water.
The fact that I do not *revere* I7 should not be misinterpreted as
dismissal. If I didn't think it worth talking about, I wouldn't bother.
I would very much like to subtract the propaganda and exaggeration from
the system -- not as an attack, but more like as a defense from unfair
praise: in other words, only so it can be appreciated for what it is.
Josh Lawrence
Hardly. There is a world of difference in using an OO language that
includes some rules-oriented aspects, and using a language that dumps
OO and puts its primary emphasis on rules. I tried T3 previously (after
trying I6 and Hugo, and looking briefly into others), and found its
robust world model appealing. But in the end its approach is not the
best or most efficient tool for me to design IF with. The overall
emphasis on rules in I7 is much better fit for how I think about and
solve design problems, and the NL syntax makes implementing these
solutions *easier* for me than I have found in other IF languages
(glancing at AIFT after your mention of it, I have to say that its
syntax immediately rubs me wrong in the same way I7's must do for you.
I recognize this as a personal preference, however.)
The NL syntax does have its own ambiguities and problem areas that need
working out, but those problems are *still* a worthwhile trade-off for
me, in the flexibility and immediate readability (what I'm doing in any
part of the code is redily apparent) it provides. Thus I find myself
going much farther with I7 and tackling more complicated problems with
it than I have with any other IF language.
However, I don't see this as revealing a flaw in T3. OO *is* fine, as
you say, but solving problems in it will be easy for some people, and
very difficult for others. I7's approach works better for me, but its
approach is understandably anathema to others. These are different
approaches to the same problem, as you say, but to suggest, in the
example of rule conflicts that you give, that the *form* of
specification of the solution is a minor thing is a huge mis-step. The
*form* of the specification determines whether the language under
question works with or against a given individual's approach to design
and problem-solving (this point is being expressed and explored in
other threads currently).
I think this is the root of the disagreement between you and Nate Cull
when discussing the I7 Planner. The fact is it was *easier* for Nate
to accomplish what he wanted to do with Planner given the built-in
rules-based nature of I7, then when he tried it OO-style. Now, whether
it would actually be impossible to achieve what he wanted in an OO
framework, I don't know, but my hunch is it would *not* actually be
impossible. But the fact of the matter is it became difficult enough
for him to do what he wanted in OO that he abandoned the problem,
whereas I7's *centrally* rule-based approach happened to synch up with
how he was thinking about the problem, and thus allowed him to move the
project forward to his satisfaction. (It is important to also note that
even given this, Nate has posted about aspects of I7 that he finds
constraining for further developments he'd like to pursue -- so he,
like most who are delving deeply into I7, are finding a mix of things
they love and hate about the system -- it is not an unqualified love
fest.) For someone who works most comfortably in OO style, using I7
would have undoutably made the problem *harder* instead of easier to
solve.
Instead of viewing them as separate "leaps", I think it is the
combination of the centrally rule-based approach, NL syntax and
relations that makes I7 a definite *leap* towards a different approach
in IF development. Coding in it and problem-solving with it are
decidedly different experiences than doing the same in other IF
languages I have explored. These differences go down to the roots of
how I think about, build and change the world model I'm working with --
therefore differences that decidedly beyond any "name-brand" cosmetic
window-dressing. What I7 provides is not the *best* solution, because
the problems of robust IF design are complicated enough there is no One
Best Approach. There are only alternate approaches that have their own
trade-offs, so I7 has its own trade-offs, and issues of current
implementation that are being worked out, but it *is* a leap in a
certain, alternate direction, because no other IF language provides the
same combination of the elements named above. This alternate direction
does work better for some people, even after the glow of the 'new and
shiny' has worn off.
<strained metaphor on>
In other words, the flip-flops under question really do provide a
different walking experience down the road of IF development. How far
one walks in them depends on how well they fit one's feet.
<strained metaphor off>
steve....@gmail.com
something about challenging I7 that brings out the devil in some
people, and I'm glad to see nothing of that here!
Josh Lawrence wrote:
> There is a world of difference in using an OO language that
> includes some rules-oriented aspects, and using a language that dumps
> OO and puts its primary emphasis on rules.
There is indeed a world of difference between a simulationist or
otherwise simplistic OO language, like I6, and a thoroughgoingly
rule-oriented language like Prolog. I7 is obviously object-driven, in
its concept, semantics, and in its implementation: to say that I7 is
rule-based is fair, but arguably an exaggeration. Likewise, you many
say that TADS 3 is OO, although it does in fact use a few rule-based
subsystems, such as the grammar/parser system and the conversation
system. So there's a world of difference between these two conceptual
models, in theory, but in fact the story is, as always, more
complicated than the advertising slogan.
> (glancing at AIFT after your mention of it, I have to say that its
> syntax immediately rubs me wrong in the same way I7's must do for you.
> I recognize this as a personal preference, however.)
Well, as far as my personal preference, rule-based systems rub me the
wrong way, and fake-NL-programming definitely rubs me the wrong way.
I'd say that the latter is my main problem with I7.
I am very happy that I7's explores rule-oriented programming, as I have
said from the beginning. I'm just unhappy with claims that this is a
quantum leap, or the frequent absolute claims in favor of rule-oriented
system for IF design. The arguments I've heard in favor of rule-based
systems, and the arguments against OO, are flimsy and oversimplified.
> The NL syntax does have its own ambiguities and problem areas that need
> working out, but those problems are *still* a worthwhile trade-off for
> me, in the flexibility and immediate readability (what I'm doing in any
> part of the code is redily apparent) it provides. Thus I find myself
> going much farther with I7 and tackling more complicated problems with
> it than I have with any other IF language.
First, I very seriously doubt that it's *possible* to work out the
problem areas of NL syntax. Second, I don't know what you mean by
flexibility, but I flatly disagree about readability.
In two languages, we have these two objects. Which is more readable to
you?
An old cracked coffin is in the Gazebo. "The coffin is old and
cracked." The coffin is a container. It is openable and closed and
fixed in place. Understand "old cracked casket" as the coffin.
vs.
coffin: OpenableContainer, Fixture
@gazebo
'coffin'
'old cracked coffin/casket'
"The coffin is old and cracked."
;
**or**
coffin: OpenableContainer, Fixture
name = 'old coffin'
vocabWords = 'old cracked coffin'
desc = "The coffin is old and cracked. "
location = gazebo
;
Personally, the last would seem to me most easy-to-read, assuming
slight familiarity with the language, the middle would seem most
easy-to-read if you know the templates and you know what you're doing.
The first is just ridiculous to me.
Also there are bugs in the first one that are entirely unapparent to
the reader; good languages try to minimize that. (Dijkstra writes that
some people "seem to equate 'the ease of programming' with the ease of
making undetected mistakes" -- which is exaxtly the point here.)
Let's consider an example of actual coding, not plain declaration: I
find Cull's I7Planner far less easy-to-read than t3RAP, or Nate's TADS2
version of RAP.
It seems very clear to me (does it really not to you?), in both these
examples, that programming in pseudo-English is distractingly silly,
spatially disorganized, unnecessarily verbose, ambiguous, and perhaps
most importantly, what the computer is reading and what the programmer
is reading are further removed than ever before.
So, while "The hat is on the bed" may at first blush look better than
"hat:object location=bed", I really don't think it's a good idea.
> [OO and rule-O] are different
> approaches to the same problem, as you say, but to suggest, in the
> example of rule conflicts that you give, that the *form* of
> specification of the solution is a minor thing is a huge mis-step. The
> *form* of the specification determines whether the language under
> question works with or against a given individual's approach to design
> and problem-solving (this point is being expressed and explored in
> other threads currently).
I don't mean to say it's minor, but to focus on that directly, or in
other words, to point out that we shouldn't pretend that in the one
framework you have the onerous job of tiebreaking, and in the other
framework all the work is magically done for you automatically, which
is the upshot of more than a few of the arguments I've heard in favor
of I7.
> I think this is the root of the disagreement between you and Nate Cull
> when discussing the I7 Planner. The fact is it was *easier* for Nate
> to accomplish what he wanted to do with Planner given the built-in
> rules-based nature of I7, then when he tried it OO-style. Now, whether
> it would actually be impossible to achieve what he wanted in an OO
> framework, I don't know, but my hunch is it would *not* actually be
> impossible. But the fact of the matter is it became difficult enough
> for him to do what he wanted in OO that he abandoned the problem,
> whereas I7's *centrally* rule-based approach happened to synch up with
> how he was thinking about the problem, and thus allowed him to move the
> project forward to his satisfaction.
No, the I7 planner does not do anything new. (In fact, the TADS 3
version has a whole lot more features.) Nate was speculating that the
rule-orientation of I7 will make it easier for game-authors to make
custom-case plans interact well with each other. This is, I think, a
restatement of Plotkin's argument, that special-case conflicts are
easier to resolve in I7 than in OO. I say that conflicts are not that
much of a problem in either case -- and I have found no problem at all
in fact with the OO approach to custom plans -- and there's a lot more
pressing problems with planners than this in any case.
> This alternate direction
> does work better for some people, even after the glow of the 'new and
> shiny' has worn off.
You might think so, but then again you might soon realise that I7 is
not what it's cracked up to be, and wish you had spent the time
learning TADS better. That's not a prediction -- hey it may be the
thing for you and good luck with it! -- but only a challenge to the
theory that people who find I7 initially appealing would ultimately
find it more workable. I6ers used to make precisely the same point
against, oh, ADRIFT for example.
Josh Lawrence
> I7 is obviously object-driven, in
> its concept, semantics, and in its implementation: to say that I7 is
> rule-based is fair, but arguably an exaggeration.
Well, to do anything to any object during play or respond to anything
the player does, you must invoke, create or alter a rule. Rules are at
the core of any interaction with the world model. So while I7's not a
pure rule-based system that relies on rules for all things, a huge
chunk of essential functionality is rule-based.
> I am very happy that I7's explores rule-oriented programming, as I have
> said from the beginning. I'm just unhappy with claims that this is a
> quantum leap, or the frequent absolute claims in favor of rule-oriented
> system for IF design.
A quantum leap, who knows, but it is a leap in that it provides a rule
based system for dealing with its world model combined with a syntax
that makes interacting with that system more approachable, or a better
conceptual fit, for some people than typical programming syntax would
be. Whether rule-based is absolutely better than OO for IF design, I
am agnostic. I only say that a rules-based approach to dealing with the
world model seems to work better for me.
> > The NL syntax does have its own ambiguities and problem areas that need
> > working out, but those problems are *still* a worthwhile trade-off for
> > me, in the flexibility and immediate readability (what I'm doing in any
> > part of the code is redily apparent) it provides. Thus I find myself
> > going much farther with I7 and tackling more complicated problems with
> > it than I have with any other IF language.
>
> First, I very seriously doubt that it's *possible* to work out the
> problem areas of NL syntax.
I'm not hoping for a ironing out of all problems of NL syntax as it
applies to programming in general, which indeed would be an incredibly
lofty goal, but I am hopeful that the problems of I7's specialized NL
syntax, as they apply to IF design, can be improved on to a
satisfactory degree. There are already various ambiguities and
conflicts that have been corrected in the bugfixes in various updates
to I7 so far, and various suggestions for changes and additions to the
syntax that have been submitted and are under consideration. Time will
tell.
>Second, I don't know what you mean by flexibility, but I flatly disagree about readability.
> In two languages, we have these two objects. Which is more readable to
> you?
>
> An old cracked coffin is in the Gazebo. "The coffin is old and
> cracked." The coffin is a container. It is openable and closed and
> fixed in place. Understand "old cracked casket" as the coffin.
>
> vs.
>
> coffin: OpenableContainer, Fixture
> @gazebo
> 'coffin'
> 'old cracked coffin/casket'
> "The coffin is old and cracked."
> ;
>
> **or**
>
> coffin: OpenableContainer, Fixture
> name = 'old coffin'
> vocabWords = 'old cracked coffin'
> desc = "The coffin is old and cracked. "
> location = gazebo
> ;
>
> Personally, the last would seem to me most easy-to-read, assuming
> slight familiarity with the language, the middle would seem most
> easy-to-read if you know the templates and you know what you're doing.
> The first is just ridiculous to me.
I agree that in examples of simple declarations like this I7 is simply
wordier and I6 and T3 cleaner. But I was thinking more of statements
that involve relations between objects and changes to the world state.
By flexibility I mean the ease with which one can define new relations
between objects through definitions, rules and, well, relations. By
readability I mean the clarity with which the NL-like syntax can allow
a particular line to literally "say" exactly how it questions or
interacts with the world model, without my having to go through several
phases of internal translation of its meaning. When looking at a
particular line of I7 I generally do much less of a Syntax Decoding -->
Logic Decoding --> Figuring Out What This Piece of Logic Does or Asks
of the World Model process. Therefore even something relatively
complicated is easily comprehended with a glance. Take some samples of
lines from Example 171 in the I7 docs, "Otranto":
<code>
A rope is a kind of thing.
Definition: a thing is nonrope if it is not a rope. [The perfect idiocy
of this statement notwithstanding, having a shortcut will come in very
handy later]
Attachment relates things to each other in groups. The verb to be stuck
to implies the attachment relation.
Definition: a thing is tied if the number of things stuck to it is
greater than 1.
Definition: a thing is free if it is not tied.
Definition: a rope is free if the number of nonrope things stuck to it
is less than 2.
Definition: a thing is hindering if it is stuck to the noun and it is
not within the location.
A thing can be round or unevenly shaped. A thing is usually round.
Definition: something is anchored if it is fixed in place or it is
scenery or it is part of an anchored thing.
Definition: something is draggable if it is not had by the player and
it is not the player and it is not anchored.
....
After printing the name of a rope (called the tied object) while taking
inventory:
if something nonrope is stuck to the tied object
begin;
say " (attached to [the list of nonrope things which are stuck
to the tied object])";
otherwise;
say " (with both ends free)";
end if.
....
Instead of tying a free nonrope thing to a free nonrope thing:
if the player carries a free rope (called the coil)
begin;
try tying the noun to the coil;
if the noun is stuck to the coil and the coil is free
begin;
try tying the second noun to the coil;
end if;
otherwise;
say "You lack the requisite spare rope.";
end if.
.....
Instead of pulling something tied:
if the noun is unmentioned
begin;
say "The impulse is transmitted to [the list of pullable things
stuck to the noun].";
repeat with item running through pullable things stuck to the
noun
begin;
say "[item]: [run paragraph on]"; try pulling the item;
end repeat;
if the noun is a rope and the noun is not within the location
begin;
if the number of nonrope hindering things is 0, move
the noun to the location;
end if;
otherwise;
continue the action;
end if.
..........
Before going a direction (called the way) when the player has something
(called the link) which is stuck to something anchored (called the
anchor):
let the next room be the home of the anchor;
if the next room is not a room, continue the action;
if the next room is the location
begin;
if the link is stuck to at least two anchored things,
say "You can't go far while you're carrying [the link] tied
to [the list of anchored things stuck to the link]." instead;
otherwise;
let the safe way be the best route from the location to the
next room;
if the safe way is the way
begin;
if the player is not stuck to the anchor, say "(coiling up
your rope again as you go...)";
otherwise;
if the safe way is a direction,
say "While you have [the link] you can't really head
any direction but [best route from the location to the next room]."
instead;
otherwise say "You're tied up here." instead;
end if;
end if.
</code>
The point is not that what's implemented here couldn't be done in OO,
or that the code is concise (which it isn't), but that the code is
easy-to-read in terms of "what's going on in the world model" being
immediately apparent. The cost of wordiness and occassional ambiguity
problems is worth it to me to gain the ability to have "Hm, I need to
test when the player goes a direction holding a rope that's tied to any
anchoring objects" translate to "Before going a direction (called the
way) when the player has something (called the link) which is stuck to
something anchored (called the anchor)" in code. Example 63, "Revenge
of the Fussy Table", while verbose, is another great example of being
able to express the desired relations between objects in the world
model, and actions that will be taken based on those relations,
*literally* in the language of the code, making those relations/actions
immediately apparent to anyone who reads it
> Let's consider an example of actual coding, not plain declaration: I
> find Cull's I7Planner far less easy-to-read than t3RAP, or Nate's TADS2
> version of RAP.
>
> It seems very clear to me (does it really not to you?), in both these
> examples, that programming in pseudo-English is distractingly silly,
> spatially disorganized, unnecessarily verbose, ambiguous, and perhaps
> most importantly, what the computer is reading and what the programmer
> is reading are further removed than ever before.
Yes, Nate himself admitted that writing more abstracted code in I7's
syntax can lead to ugliness. That is an admitted weakness of I7. But
despite the tangled nature of the Planner code itself, writing plans
that use it is quite easy, and another example of the 'the function of
this code is directly apparent' aspect of I7 I like:
<code>
Planning when the desired relation is trapped-in and the desired param1
is an animal and the desired param2 is a trap (this is the basic
trapping rule):
plan 1;
suggest being-carried-by with the desired param2 and the
planning actor;
suggest being-open with the desired param2;
suggest being-touchable-by with the desired param1 and the
planning actor;
suggest trapping-it-now with the desired param1 and the
desired param2;
suggest doing-dropping with the desired param2;
</code>
All the relations/actions besides trapping-it-now (a custom action I
define elsewhere) are the familiar built-ins, and what this plan does
should be readily apparent.
> > [OO and rule-O] are different
> > approaches to the same problem, as you say, but to suggest, in the
> > example of rule conflicts that you give, that the *form* of
> > specification of the solution is a minor thing is a huge mis-step. The
> > *form* of the specification determines whether the language under
> > question works with or against a given individual's approach to design
> > and problem-solving (this point is being expressed and explored in
> > other threads currently).
>
> I don't mean to say it's minor, but to focus on that directly, or in
> other words, to point out that we shouldn't pretend that in the one
> framework you have the onerous job of tiebreaking, and in the other
> framework all the work is magically done for you automatically, which
> is the upshot of more than a few of the arguments I've heard in favor
> of I7.
Well, again I'm not making that argument and I haven't had enough
hands-on experience with the T3 Planner and making custom plans with it
to judge the "rules solves tricky tie-breaking better than OO"
argument. But I know I'm interested in experimenting with the I7
version, because its particular rule-based nature is more appealing to
me.
> > This alternate direction
> > does work better for some people, even after the glow of the 'new and
> > shiny' has worn off.
>
> You might think so, but then again you might soon realise that I7 is
> not what it's cracked up to be, and wish you had spent the time
> learning TADS better. That's not a prediction -- hey it may be the
> thing for you and good luck with it! -- but only a challenge to the
> theory that people who find I7 initially appealing would ultimately
> find it more workable. I6ers used to make precisely the same point
> against, oh, ADRIFT for example.
Sure, if I encounter enough intractable problems with I7, I will
abandon it. But I think its different approach has already proved
enriching and enjoyable experience, so I feel doubtful that I'll
consider it wasted time even if that outcome occurs. I don't consider
my time spent with T3 wasted even though I moved away from it, as it
was very interesting to see such a thoroughly-implemented built-in
world model.
Chuck
I admit to being a total newbie to Inform. I learned SUDS (gasp!), then
Quest, then ADRIFT. I looked at TADS and Inform and realized that it
would take too long and require a greater time commitment to hammer out
a good story in those formats. I'm a storyteller and writer (published
five books but none fiction) not a programmer. I've been away from IF
for almost two years working on academic projects and only recently
decided to return to my story, "The Adventures of Phoebe McGee," that
is about half done in ADRIFT. I started poking around to see what's new
and discovered Inform 7.
I almost peed my pants as I looked through the incredible documentation
at the website.
I am stunned by the accomplishment. I mean that. I was so excited that
I could hardly sleep on Saturday night.
I printed off about 650 pages of docs on my laser printer and have
started to recast my story in Inform 7 as I learn. I am a greybeard and
gradually approaching retirement age. I don't golf or fish. I'm now
licking my chops at the prospect of being able to work full-time in IF
in about six years. Until then, it's certainly a little more than a
part-time love.
My take on Inform 7? For someone like me, it's incredible because I can
focus more on the logic and content of my storytelling without having
to penetrate the mysteries of earlier versions.
I can understand why some Inform devotees would be threatened by people
like me being involved and doing well in Inform 7 (hope, hope, hope).
Inform 7 allows people like me to look behind the screen to make
friends with the real Wizard of Oz. Inform 7 opens up the playing field
to users who shied away from earlier versions of Inform. Does this
reduce the status of established Inform Experts by inviting the
Unwashed Masses to begin using the tool? Not in my eyes. I certainly
respect those of you who have expertise in Inform and have used it to
create great stories. I am and will continue to be awed by your
accomplishement.
I think IF needs the largest playing field possible. Inform 7 is not
going to be easy to learn so only the committed will be able to produce
anything worth attention. I expect to spend months going systematically
through the amazingly great documentation.
And most of all, I want to thank the creators of Inform 7. This product
is clearly the labor of love by professionals who not only had the
programming knowledge to pull it off but the humanity to create an
elegant and inviting interface. THANK YOU!
Chuck
Kansas State University
http://www.raisingcourageouskids.com
http://www.ksu.edu/wwparent/
Andrew Plotkin
>
> My take on Inform 7? For someone like me, it's incredible because I can
> focus more on the logic and content of my storytelling without having
> to penetrate the mysteries of earlier versions.
>
> I can understand why some Inform devotees would be threatened by people
> like me being involved and doing well in Inform 7 (hope, hope,
> hope).
What, you hope I feel threatened? :)
I can't say that *nobody* feels this way -- I have heard such
sentiments attributed to at least one person. (Not on this newsgroup.)
But I am comfortable saying that most Inform devotees are thrilled to
see new authors getting involved and writing IF.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're an American.
Joe Majsterski
Andrew Plotkin wrote:
> Here, Chuck <cas...@ksu.edu> wrote:
> >
> > My take on Inform 7? For someone like me, it's incredible because I can
> > focus more on the logic and content of my storytelling without having
> > to penetrate the mysteries of earlier versions.
> >
> > I can understand why some Inform devotees would be threatened by people
> > like me being involved and doing well in Inform 7 (hope, hope,
> > hope).
>
> What, you hope I feel threatened? :)
>
> I can't say that *nobody* feels this way -- I have heard such
> sentiments attributed to at least one person. (Not on this newsgroup.)
> But I am comfortable saying that most Inform devotees are thrilled to
> see new authors getting involved and writing IF.
I just have to remark that it is the strangest coincidence for me. I
got involved in IF just as all these new versions of esablished
languages were coming out purely because of a nostalgia trip I started
on due to the very recent release of "Dreamfall: The Longest Journey."
It's a very well put together modern adventure game that got my juices
flowing for adventure gaming in general. I ended up backtracking
through the adventure games of the last decade, and finally into IF
from the 1980s. I had no choice but to start working on my own
projects, and I'm thrilled that there are so many options for design at
this point. I will say, however, that after examining the field, I7 is
definitely the most appealing to me. The IDE is wonderful, and the
language itself seems very robust. I think one of the best features,
however, is the fact that it is basically a self-documenting language.
There is practically zero need for any additional comments, simply
because the language itself is so natural and easy to follow. "The
kitchen is a room." Yeah, I think I can follow.
na...@natecull.org
For sake of comparison: I experimented today with translating the above
I7 code into Prolog, assuming a somewhat I7-like Prolog support library
which I am kind of tinkering with at the moment. Much of the statements
about the world are RDF-like (subject, predicate, object) triples.
'Definitely' defines a statement or rule which is true at all times,
and checked before the world model. 'Generally' defines a statement
which is checked as a last resort, after the world model. 'Initially',
not used here, defines an initial condition of the world which can
change. The object model is prototype, multi-inheritance rather than
class-based single-inheritance ('isa' indicates a child-of relation in
the prototype tree). 'c' is a shorthand for 'currently'. I think I've
got the 'if/then' syntax right - Prolog's conditionals are not a thing
of beauty.
definitely(rope, isa, thing).
definitely(X, is, nonrope) :- \+ currently(X, isa, rope).
definitely(attachedto, isa, relation).
definitely(X, is, tied) :- count(currently(_,attachedto,X)) > 1.
definitely(X, is, free) :- \+ currently(X, isa, rope), \+ currently(X,
is, tied).
definitely(X, is, free) :- currently(X, isa, rope), \+ currently(X, is,
tied).
definitely(X, is, hindering) :-
global(noun, Noun),
currently(player, locatedin, Location),
currently(X, attachedto, Noun),
\x currently(X, within, Location).
definitely(thing, iseither, [round, unevenly_shaped]).
generally(thing, is, round).
definitely(X, is, anchored) :- currently(X, is, fixed_in_place).
definitely(X, is, anchored) :- currently(X, is, scenery).
definitely(X, is, anchored) :- currently(X, partof, Assembly),
currently(Assembly, is, fixed_in_place).
definitely(X, is, draggable) :-
\+ currently(X, hadby, player),
\+ currently(X, is, player),
\+ currently(X, is, anchored).
rule(_,after(activity(printing_name_of,TiedObject))),
c(TiedObject, isa, rope),
during_activity(taking_inventory),
c(Something, attachedto, TiedObject),
( c(Something, is, nonrope) ->
say(["(attached to ", list([nonrope, [stuckto, TiedObject]]) ;
say("(with both ends free)") ;
)
rule(_,instead(action(player,tying,X,Y))) :-
c(X,isa,thing),c(X,is,free),c(X,is,nonrope),
c(Y,isa,thing),c(Y,is,free),c(Y,is,nonrope),
( c(player,carrying,Coil) ->
global(noun,Noun),
try(action(player,tying,Noun,Coil)),
( c(Noun,attachedto,Coil), c(Coil,is,free) ->
global(second,Second),
try(action(player,tying,Second,Coil)) ;
true ;
) ;
say("You lack the requisite spare rope.").
The result, as you can tell, is rather depressing for readability. Even
'Fake-NL' English is *very* dense in information.
Doggone it, and I *still* think there can be a readable regular syntax,
but this ain't it.
Emily Short
na...@natecull.org wrote:
> rule(_,instead(action(player,tying,X,Y))) :-
> c(X,isa,thing),c(X,is,free),c(X,is,nonrope),
> c(Y,isa,thing),c(Y,is,free),c(Y,is,nonrope),
> ( c(player,carrying,Coil) ->
> global(noun,Noun),
> try(action(player,tying,Noun,Coil)),
> ( c(Noun,attachedto,Coil), c(Coil,is,free) ->
> global(second,Second),
> try(action(player,tying,Second,Coil)) ;
> true ;
> ) ;
> say("You lack the requisite spare rope.").
>
>
>
>
> The result, as you can tell, is rather depressing for readability. Even
> 'Fake-NL' English is *very* dense in information.
Yeah, my brain hurts a bit looking at this. I'm not sure how much of
this is down to the conditions being unfamiliar, though; I am betting
that if that aspect were more obvious to me, I'd have an easier time
with it.
Hm.
na...@natecull.org
The structure of Prolog clauses is pretty simple: 'this condition is
considered true if all of these conditions, evaluated in strict
sequential order, return true'. Upper-case names are temporary
variables.
A lot of the complexity in this rule definition comes from the fact
that I7 is strongly typed (and allows not only kinds but adjectives to
be used as guard conditions in a rule definition), while Prolog is
untyped and has to do all its checking manually. So instead of saying
'... tying a free nonrope thing to a free nonrope thing' I have to
check that both of the two arguments are things that exist, are 'free'
and are 'nonrope'.
Another thing that uglifies it greatly is that Prolog is one of those
strict bondage-and-discipline languages beloved of the likes of Niklaus
Wirth, so it doesn't have such a thing as global variables. I am
simulating globals here with a 'global(Variable, Value)' predicate
which fetches the current value of a global and binds it to a logical
variable for this clause. Probably a more 'Prologgy' way of doing this
would be to pass a structure containing the current action to each
rule, but that's just ick and gross, not to mention not extendable.
I've been reading Carl Hewitt and Terry Winograd's PLANNER/SHRDLU
papers, and it seems that PLANNER (Prolog's ancestor) took a much more
easygoing and pragmatic view of this, much like I7 does; it allowed
the programmer to mix logical conditions and, procedural code, and
stored all sorts of global state at various points in the process. No
doubt this drove the purists crazy, but it worked.
na...@natecull.org
Emily Short wrote:
> na...@natecull.org wrote:
> > rule(_,instead(action(player,tying,X,Y))) :-
> > c(X,isa,thing),c(X,is,free),c(X,is,nonrope),
> > c(Y,isa,thing),c(Y,is,free),c(Y,is,nonrope),
> > ( c(player,carrying,Coil) ->
> > global(noun,Noun),
> > try(action(player,tying,Noun,Coil)),
> > ( c(Noun,attachedto,Coil), c(Coil,is,free) ->
> > global(second,Second),
> > try(action(player,tying,Second,Coil)) ;
> > true ;
> > ) ;
> > say("You lack the requisite spare rope.").
Also, I had a brain-lapse while writing this and forgot I was already
passing noun as an argument. And it's buggy. A better version would be
something like:
rule(myrule, instead(player,tying,Noun,SecondNoun)) :-
c(Noun,isa,thing), c(Noun,is,free),c(Noun,is,nonrope),
c(SecondNoun,isa,thing),
c(SecondNoun,is,free),c(SecondNoun,is,nonrope), !,
c(player,carrying,Coil), c(Coil,is,free), c(Coil,isa,rope) ->
tierope(Noun,Second, Coil)
; say("You lack the requisite spare rope.").
tierope(Noun,Second,Coil) :-
c(Noun,attachedto,Coil), c(Coil,is,free) ->
try(player,tying,Second,Coil) ; true.
and still ugly, owing to lack of nested conditionals. I think a custom
Micro-Planner like language with its own pattern-matching semantics
(and real functions) is called for.
John Prevost
na...@natecull.org wrote:
> and still ugly, owing to lack of nested conditionals. I think a custom
> Micro-Planner like language with its own pattern-matching semantics
> (and real functions) is called for.
I've been thinking a bit about a logical programming language that
supports syntax extension as a basic feature. (Generally, for
mixfix-style relational operators.) It could have a prolog-like syntax
to start, but be extended to allow more natural declarations.
For example:
{X is a Y} := exists(X), is_kind(Y), has_kind(X,Y).
The other thought I had is the idea of an "implication" for
compile-time statements. In Prolog, you can write something like the
following if you want three things to become true when one thing is
true:
exists(X) :- is_a(X,Y).
exists(Y) :- is_a(X,Y).
has_kind(X,Y) :- is_a(X,Y).
And if you want the other direction to hold as well:
is_a(X,Y) :- exists(X), exists(Y), has_kind(X,Y).
But this is quite clunky when you want a single phrase of input to
cause multiple things to come true (as in Inform7, where saying "X is
north of Y" causes X and Y to be considered to exist, and to be rooms.)
So something like:
{X exists}. (* This just declares that this syntax expresses a
relation. *)
{X has kind Y}. (* etc. *)
{X is a kind}.
X is a Y <=> X exists, Y is a kind, X has kind Y.
The <=> operator here is an "if and only if". If "The book is a thing"
is seen as a statement, then the statements "(The book) exists", "(a
thing) is a kind", and "(the book) has kind (a thing)" would be true as
well. If you had "the book is a thing" as one of the conditions for a
predicate, it would be true as long as the book exists, a thing is a
kind, and the book has kind a thing, regardless of how those things
came to be true.
The main thing I haven't put a lot of though into yet is how to handle
precedence of rules. There's a kind of modal logic there (statements
have different kinds of trueness: always true, usually true, used to be
true...)--setting a default "X smells of nothing :- X is a thing" and
then a specific rule "X smells of sweetness :- X is a flower" would
want to override. But in Prolog, of course, you get the answers in the
order that the search finds them. It makes sense there--you're getting
back *all* of the answers. But here, you sometimes want one preferred
answer. (Likewise with parsing: parsing in a logical language is
suprisingly easy to model--but will give you back all of the possible
parse trees, whereas we'd want to choose one preferred tree.)
(As a note, part of why I started thinking about mixfix parsing is that
I was frustrated that I generally had to write R(w,x,y) for relations
that I would write on a board or on paper as something like "G |- e :
t". It was only later that I thought about thinking about words as
notation, and the possibility of using such a notation to define a
world for IF. This is part of why I've been super excited about
Inform7... the above model for defining IF using a logical language
struck me a couple of years ago, and Inform7 strikes *close* to what I
was imagining.)
Anyway, some food for thought. If I'm lucky, maybe I'll have time to
play with this idea more later.
steve....@gmail.com
> Yeah, my brain hurts a bit looking at this.
If we say that the I7 version is easier to read, we probably mean that
it's easier to figure out what the writer is trying to do -- regardless
of whether or not it works. But if you're reading this to understand
what the code is actually doing, you have to mentally parse each
statement the same way (not exactly the same, but the same basic mental
process), and so the clarity and spatial organization of the Prolog
version seems to me a big improvement, making the code *much* easier to
read.
For instance, one nice thing about the Prolog version is that it's
pretty easy to see whether or not the program will run. About 99% or my
time spent in Inform7 coding is figuring out what English sentence is
acceptable Inglish for a given statement -- bugs aside, just what will
compile!
I am reminded of the huge distinction between recognition and
expression, painfully sharp when one is learning a foreign (natural)
language. It's always much easier to read or listen than it is to write
or speak. I7 widens this gap substantially, by presenting a language
that reads as familiar but which works by a set of rules all the more
terribly foreign for the false familiarity.
vaporware
> If we say that the I7 version is easier to read, we probably mean that
> it's easier to figure out what the writer is trying to do -- regardless
> of whether or not it works. But if you're reading this to understand
> what the code is actually doing, you have to mentally parse each
> statement the same way (not exactly the same, but the same basic mental
> process),
Most of us are already used to that mental process every day, because
reading Inform 7 code is much like reading English. Some terms have
special meanings, but it's no more awkward than reading a trade
magazine, encyclopedia, or newsgroup post.
> For instance, one nice thing about the Prolog version is that it's
> pretty easy to see whether or not the program will run. About 99% or my
> time spent in Inform7 coding is figuring out what English sentence is
> acceptable Inglish for a given statement -- bugs aside, just what will
> compile!
That just means you need more time getting used to the language. I had
the same problem when I first learned C.
vw
steve....@gmail.com
> > If we say that the I7 version is easier to read, we probably mean that
> > it's easier to figure out what the writer is trying to do -- regardless
> > of whether or not it works. But if you're reading this to understand
> > what the code is actually doing, you have to mentally parse each
> > statement the same way (not exactly the same, but the same basic mental
> > process),
>
> Most of us are already used to that mental process every day, because
> reading Inform 7 code is much like reading English.
Yes, in the former sense; and in this sense you are reading English,
and not computer code at all. But not in the latter sense, when you're
understanding what the code is doing. That level obviously does not
exist when you're reading regular English. (You don't bench-check
English, for instance.)
What is important here is that there are two totally distinct levels:
how the program reads when it's taken as English, and what the program
means in terms of what it will do, which requires the same reading
technique that the equivalent Prolog code requires.
Now, I7 makes noble efforts to align these two, but they are totally
distinct, and when one suggests that I7 is easier to read than typical
computer code, I think this distinction is being forgotten. In a way it
is arguably true...
But even so, the gain can be overestimated. I mean, after all -- why
not just use comments, if you want a non-programmer to be able to read
what the code does -- or better yet, just write a manual?
The real claim is that making Inglish look like English is that it
makes code easier to *write*, which gets us into the second point....
> > For instance, one nice thing about the Prolog version is that it's
> > pretty easy to see whether or not the program will run. About 99% or my
> > time spent in Inform7 coding is figuring out what English sentence is
> > acceptable Inglish for a given statement -- bugs aside, just what will
> > compile!
>
> That just means you need more time getting used to the language. I had
> the same problem when I first learned C.
No, that's not the point. Yes, the more familiar you are, the better
you get at writing Inglish, or writing English that passes the compiler
as Inglish. But the problem I'm identifying, although it plagues
learners far more than it plagues gurus, is not lack of familiarity --
and I don't think it can be belivably dismissed as such.
The point is that it doesn't write like English at all, and that it
*appears* to write like Engligh makes one considerably more confused
than would otherwise be necessary -- This because 1) one will naturally
fall into thinking in real English, rather than in a formal symbolism;
2) the formal symbolism could be simpler were it not trying to read
like English; and 3) one will have to remember which English
constructions are valid Inglish, and one will have to remember which
similar English constructions are not, whereas if there's one symbolic
way it's a sinch to memorize it.
Thus I say that the foreign-ness of traditional programming languages
makes them considerably easier to learn for a number of reasons. I hope
the logic is now clearer.
I hope it's also clear why I'm saying that the "readability" of I7 on
one level comes at a cost to readability on what I take to be the much
more important level, the level on which the work of programming is
actually done. For although on one level it reads like English, on
another level it reads like highly verbose and spatially disorganized
code, the meaning of which is occluded by the operations of a parser
whose sophistications and complications far exceed the needs of normal
formal symbolism (like C, to take your example).
Kyle Pierce
na...@natecull.org wrote:
> I think a custom
> Micro-Planner like language with its own pattern-matching semantics
> (and real functions) is called for.
One useful way to make use of Prolog could be to create a custom
language of this sort by building on all the work that has been done in
Prolog on language parsers. A possible starting point would be:
http://ai.uga.edu/mc/pronto/ which has a bunch of SWI-Prolog compatible
code and references. There are others as well, just google "Prolog NLP
grammars".
Starting from the existing Prolog projects that are available, it is
practical to implement a parser for a limited and well-defined subset
of English grammar. I too am looking for more control over
pattern-matching semantics and other functionality.
So, good luck with your work.
Kyle
ChicagoDave
> Thus I say that the foreign-ness of traditional programming languages
> makes them considerably easier to learn for a number of reasons. I hope
> the logic is now clearer.
>
Considerably easier for whom? Are you making suggesting that all humans
will communicate logical patterns in exactly the same ways?
Is it not possible that some people break down logic in a narrative
form and some people break down logic in a mathematical form? Some
others might see things in shapes or colors. Still others might break
down logic using pseudo code of their own devising.
I've been writing code for twenty-six years and I know where my skills
fall. If the problem I'm defining has a particular way to be defined,
then I would much rather use that particular way than be forced to use
a generic or alternate method to resolve my problem.
Here's an example....
RPG was originally created by IBM to be a Report Program Generator
compiler. It was meant to write reports. But the brilliant people at
IBM (I'm not joking) thought RPG was such an interesting paradign (the
cyclical operation pattern) that they thought they could easily evolve
the syntax into doing "other things besides reporting".
I've written reports in RPG II and RPG III. It's not a bad syntax to do
that kind of work in.
But I've also had to create data entry systems in RPG II/III and let me
tell you _that_ isn't something RPG was meant to do.
This would be like taking Inform 7 and trying to create an operating
system. I'm sure some hacker out there reading this is thinking, "hey -
I can do that!" but that's not the "problem space" Inform 7 is
targeting.
But your argument has consistently been that basing _any_ programming
syntax on English is wrong.
I would agree that a generic or general programming language probably
needs mathematical capabilities as a root element, although I won't say
that it absolutely needs that property. A general programming language
probably needs a lot of other things that have nothing to do with
Interactive Fiction.
But I will absolutely disagree with you that a domain specific language
(DSL) has to have this property. Inform 7 is a DSL. It is not intended
to solve math problems or print reports. It is intended to form logical
relationships for text to be input and output in a very thinly
specified manner (Interactive Fiction as generally defined by the
"Infocom standards"). This is such a narrow focus even for a DSL that
using English is an entirely appropriate option.
You keep trying to plant Inform 7 in the garden of general use
programming syntaxes and it was never intended to grow there. Would you
argue that a banana tree must grow in Northern Minnesota or well it's
not _really_ a tree then, is it?
If you don't like English in programming scenarios (DSL or not), that's
fine. We get that. But your likes and dislikes are not universal fact
and you can dig up any dead programmer you want and it won't change the
fact that your arguments are specious at best.
David C.
Rikard Peterson
@i42g2000cwa.googlegroups.com:
> Would you argue that a banana tree must grow in Northern Minnesota
> or well it's not _really_ a tree then, is it?
Right. A banana is a herb, and not a tree. ;)
--
Rikard
http://www.trumgottist.com/
steve....@gmail.com
> > Thus I say that the foreign-ness of traditional programming languages
> > makes them considerably easier to learn for a number of reasons. I hope
> > the logic is now clearer.
>
> Considerably easier for whom?
For programmers, yes. And including people who want to learn to program
IF using I7.
> Are you making suggesting that all humans
> will communicate logical patterns in exactly the same ways?
No, I'm certainly not saying everybody thinks a certain way. Here's
what I am saying in this context:
Complicating a syntax with the intention of making it look like English
does not make programming any easier. Formal symbolism is easier,
partially because it is unnatural.
I'm not saying that NL should not be adopted: it can be usefully
adopted. I'm only saying that it should not be adopted "whole hog",
that symbolism is easily learned, and clarity is the virtue.
> Is it not possible that some people break down logic in a narrative
> form and some people break down logic in a mathematical form? Some
> others might see things in shapes or colors. Still others might break
> down logic using pseudo code of their own devising.
These things have been demonstrated, they are widely believed, and I
believe them personally.
> If the problem I'm defining has a particular way to be defined,
> then I would much rather use that particular way than be forced to use
> a generic or alternate method to resolve my problem.
Here's the situation I normally find: I have a hazy sense what I want
to accomplish, and I want to make rigorous this sense, as I codify it.
So I try to figure out what I mean to myself, as I express the idea in
a way that the computer will understand. The rigor is as useful for the
articulation of the thought as it is for the codification of the
thought.
> [Y]our argument has consistently been that basing _any_ programming
> syntax on English is wrong.
Respectfully, that's an oversimplification of a (hopefully) more
sophisticated range of points, although perfectly understandable. No
harm! But let me explain a couple of those points a bit more clearly.
Basing a syntax on English is problematic, because you want it to be
formal and clear while at the same time being natural, but the very
naturalness is a way against rigor, formality, and the degree of
clarity necessary for communicating to a machine an adequately exact
specification.
Ok, this may not be an insurmountable problem, but the way out would
seem to be to make the adoption of NL a modest one, to make use of the
compactness of NL in those contexts where precision is not lost, but to
use a more conventional formal symbolism (like we find in either C or
Prolog) as soon as it's useful.
> You keep trying to plant Inform 7 in the garden of general use
> programming syntaxes and it was never intended to grow there.
This is probably a good criticism. My main criteria for a cutting-edge
IF programming language is that it has a lot of general programming
power. It's all well and good to write a language which can make
traditional games, but that closes off the genre.
On the other hand, I think some features of the I7 language open and
expand the language. I was excited to see that rule- and relation-based
programming is in the works popularly. I've been excited in the
prospect for several years, despite the fact that I personally don't
think along these lines.
Chephren
> ChicagoDave wrote:
> > > Thus I say that the foreign-ness of traditional programming languages
> > > makes them considerably easier to learn for a number of reasons. I hope
> > > the logic is now clearer.
> >
> > Considerably easier for whom?
>
> For programmers, yes. And including people who want to learn to program
> IF using I7.
>
Well, this can be resolved by an empirical test. There is little point
in arguing whether traditional languages or I7 is easiar for
programming. Rather, we should have an empirical survey of people's
experiences of the different paradigms, and from there draw an
explanation.
Part of the contention, I think, is that Steve's arguments seem to
conflict with people's experiences. Steve is saying that NL as it is
employed by I7 is more difficult than normal programming (even for the
domain of IF), but others argue they have found the approach makes IF
development easiar.
So what are the facts? What percentage of people found I7 facilitates
their IF programming, and what percentage that it inhibits it? This is
a question to programmers and non-programmers alike.
ChicagoDave
> So what are the facts? What percentage of people found I7 facilitates
> their IF programming, and what percentage that it inhibits it? This is
> a question to programmers and non-programmers alike.
I think productivity and quality will be the judge here. In a years
time, will there be more games and of what quality.
I'm not sure even that outcome will prove or disprove anything.
I can only say that for me, the level of productivity has increased
dramatically and not even in the "lines of code" sense. My view of
developing IF has entirely changed. I feel like a painter now. I can
see the game in layers I had not considered before. I started with an
overall idea. I painted the setting (map). Then I added some of the
basic puzzle ideas. Then I went to the bottom of my source and in a
comment drew up a narrative of the entire game, breaking down each
scene, the locations involved, and the plot points that relate. I've
identified areas to draw conflict and resolution. I have a clear list
of things I need to research to add detail to my NPC's and
conversations. Then I went back and developed the PC and the first few
NPC's. Then I went back and updated my narrative. Now I'm in the
details stage and really have just a list of tasks to accomplish. I'm
sure I will add a few more puzzles, a plot point here or there, but the
arc of the game is set. I probably will be in beta testing in a month.
I will have completed an 80 room game with 10 scenes in about 3 months
that has several pivotal NPC's.
And absolutely none of this has had anything to do with "how will I
code this?"
I can assure you, in any other IF platform this would have been a year
or more of work and I wouldn't have "seen" the story as I do with I7.
I might be argued that I have simply made the transition to thinking in
the manner required to develop IF, but I think that I7 and my thinking
have been married in such a way that would not happen in another syntax
or paradigm.
David C.
steve....@gmail.com
> There is little point
> programming.
I disagree. It's a really useful discussion for future systems design.
One of the major goals of I7 was to produce this discussion.
> Rather, we should have an empirical survey of people's
> experiences of the different paradigms, and from there draw an
> explanation.
Of course I agree that the utility of the system is the main question,
but I expect that the utility or usability of the system can be
confused with its used-ness, and I doubt there's a way to distinguish,
by survey, between frequency-of-use and value.
That the "Inform" label is attached to I7 virtually assures its success
as a widely used language. (I congratulate Graham for taking this
assured success and doing something interesting with it.) The used-ness
is beyond question, and it's worth inquiring the utility.
That said, I believe that if you take a survey right now, most
experienced IF writers will express mixed feelings on the overall
benefit of NL programming.
Most will say that the main benefit of I7 is the relational logic and
the rule-orientation, not the NL gloss.
> So what are the facts? What percentage of people found I7 facilitates
> their IF programming, and what percentage that it inhibits it? This is
> a question to programmers and non-programmers alike.
To draw a theory from some average of disparate personal experiences
means to disqualify certain useful lines of inquiry from the beginning.
It's another approach to systems theory, I suppose, but I don't see any
benefit to counterbalance the obvious loss of critical thought.
steve....@gmail.com
> I can only say that for me, the level of productivity has increased
> dramatically and not even in the "lines of code" sense. My view of
> developing IF has entirely changed. I feel like a painter now. I can
> see the game in layers I had not considered before.
This is great. I7 inspired you. But look again at the description, and
can you point to a single aspect, one single aspect, that has anything
to do with the programming language:
> I started with an
> overall idea. I painted the setting (map). Then I added some of the
> basic puzzle ideas. Then I went to the bottom of my source and in a
> comment drew up a narrative of the entire game, breaking down each
> scene, the locations involved, and the plot points that relate. I've
> identified areas to draw conflict and resolution. I have a clear list
> of things I need to research to add detail to my NPC's and
> conversations. Then I went back and developed the PC and the first few
> NPC's. Then I went back and updated my narrative. Now I'm in the
> details stage and really have just a list of tasks to accomplish. I'm
> sure I will add a few more puzzles, a plot point here or there, but the
> arc of the game is set.
It sounds like a Crane-esque fit of creativity, but I do not have any
reason that compels me to believe that I7 has anything to do with it.
If you said this or that aspect of I7 made it easier....
One of the things I'm trying to accomplish is that people don't
celebrate I7 uncritically in a way that accidentally damages the
further development of the genre. Please don't think that I'm scolding
people for liking it. You're inspired, that's great, no matter the
theory.
ChicagoDave
> This is great. I7 inspired you. But look again at the description, and
> can you point to a single aspect, one single aspect, that has anything
> to do with the programming language:
This is a fair question and I absolutely can answer it, but I won't at
the moment. I will finish this WIP, the next two games, and then I will
have a well-rounded view of all of the aspects I will need within I7.
Then I will be able to literally walk you through the aspects of Inform
7 that I found easier and give you examples of source that illuminate
the differences.
For now, you will have to trust me and allow for a transemperical
evaluation of Inform 7.
David C.
Kevin Forchione
news:1152917325.8...@s13g2000cwa.googlegroups.com...
>> Chephren wrote:
>> So what are the facts? What percentage of people found I7 facilitates
>> their IF programming, and what percentage that it inhibits it? This is
>> a question to programmers and non-programmers alike.
>
> I think productivity and quality will be the judge here. In a years
> time, will there be more games and of what quality.
The IDE alone would guarantee that!
> I'm not sure even that outcome will prove or disprove anything.
>
> I can only say that for me, the level of productivity has increased
> dramatically and not even in the "lines of code" sense. My view of
> developing IF has entirely changed. I feel like a painter now.
<snip>
I believe that all of the illustrations that you make point to something
which I suspect is at the root of one's increased productivity here. I
suspect that the more declarative the model used to implement IF (regardless
of the language's syntax), the more productive one is going to feel and be.
Think about it from a psychological perspective... In order to code in a
declarative language you have to tell the computer explicitly what the
desired result is. The *how* of the solution is implicitly resolved in the
underlying algorithms of the declarative system. In an imperative language
you have to tell the computer explicitly *how* to reach the solution, while
the definition of the problem remains implicit in those instructions.
Now it's my belief that it's easier for *most* people to describe what they
want rather than how to get it. There is generally manifold more complexity
in describing the *how* of a solution than in describing the *what* of the
solution.
--Kevin
David Tanguay
> Part of the contention, I think, is that Steve's arguments seem to
> conflict with people's experiences. Steve is saying that NL as it is
> employed by I7 is more difficult than normal programming (even for the
> domain of IF), but others argue they have found the approach makes IF
> development easiar.
>
> So what are the facts? What percentage of people found I7 facilitates
> their IF programming, and what percentage that it inhibits it? This is
> a question to programmers and non-programmers alike.
To know the facts, we would first have to separate out the various changes
of I7. E.g., Steve has been arguing that NL is bad. Suppose he's right: the
declarative nature (and IDE, whatever else) may be such pluses as to
overcome the NL drag.
The only way to begin to see whether NL is a plus or minus is to first make
a formal / mathematical / traditional programming (whatever you call it,
a BNF grammar thingy) syntax for the underlying I7 system, and then see how
the two compare.
In another way, the NL seems to be a big win. It may not mean much to
experienced programmers, but (from the various postings) it seems to have
created a comfort level for non-programmers. Even if it turns out to be a
false comfort in the longer run, it gets them over the initial inertial
resistance to trying something new and difficult.
--
David Tanguay Kitchener, Ontario
vaporware
> vaporware wrote:
> > > If we say that the I7 version is easier to read, we probably mean that
> > > it's easier to figure out what the writer is trying to do -- regardless
> > > of whether or not it works. But if you're reading this to understand
> > > what the code is actually doing, you have to mentally parse each
> > > statement the same way (not exactly the same, but the same basic mental
> > > process),
> >
> > Most of us are already used to that mental process every day, because
> > reading Inform 7 code is much like reading English.
>
> Yes, in the former sense; and in this sense you are reading English,
> and not computer code at all. But not in the latter sense, when you're
> understanding what the code is doing. That level obviously does not
> exist when you're reading regular English. (You don't bench-check
> English, for instance.)
No, but you do proofread English for correctness, including the use of
particular phrases that have specific meanings within a field.
> What is important here is that there are two totally distinct levels:
> how the program reads when it's taken as English, and what the program
> means in terms of what it will do, which requires the same reading
> technique that the equivalent Prolog code requires.
One of I7's goals, it seems to me, is to make those the same: the
meaning you get from reading it as English should be an accurate
description of how the program behaves. Cases where the program does
something different from what it says it does are considered bugs.
> Now, I7 makes noble efforts to align these two, but they are totally
> distinct, and when one suggests that I7 is easier to read than typical
> computer code, I think this distinction is being forgotten. In a way it
> is arguably true...
>
> But even so, the gain can be overestimated. I mean, after all -- why
> not just use comments, if you want a non-programmer to be able to read
> what the code does -- or better yet, just write a manual?
Because writing comments and manuals is *work*, a kind of work that
many programmers hate doing. Maintaining them is also work: when you
change the code, you have to update the comments and manuals. In I7,
the code itself is a good description of what it does, and comments are
mainly only needed for explaining *why* that has to be done.
> The real claim is that making Inglish look like English is that it
> makes code easier to *write*, which gets us into the second point....
More specifically, makes code easier to write for fiction authors, who
are already familiar with English but may never have typed a { } in
their life.
> The point is that it doesn't write like English at all, and that it
> *appears* to write like Engligh makes one considerably more confused
> than would otherwise be necessary -- This because 1) one will naturally
> fall into thinking in real English, rather than in a formal symbolism;
> 2) the formal symbolism could be simpler were it not trying to read
> like English; and 3) one will have to remember which English
> constructions are valid Inglish, and one will have to remember which
> similar English constructions are not, whereas if there's one symbolic
> way it's a sinch to memorize it.
You sure make it sound difficult, but I for one have no trouble with
it, and neither do many other users. Why do you suppose that is?
My favorite theory is that I'm just a super-genius. Another possibility
is that anyone with enough programming experience is used to thinking
of language in terms of rigid syntax, where similar phrasings are not
equivalent and must be kept straight in the mind. But I suspect the
real answer is that remembering particular phrasings just isn't very
tough for most people.
> Thus I say that the foreign-ness of traditional programming languages
> makes them considerably easier to learn for a number of reasons. I hope
> the logic is now clearer.
Clearer, perhaps. More convincing, no. You're arguing against the
evidence; if I7 really is as inscrutable as you describe it, where's
all the wailing and gnashing of teeth from frustrated users who just
can't grasp the difference between the correct "something carried by
Anna" and the incorrect "something Anna is carrying"? I7 seems to have
generated no more confusion than other systems.
> I hope it's also clear why I'm saying that the "readability" of I7 on
> one level comes at a cost to readability on what I take to be the much
> more important level, the level on which the work of programming is
> actually done.
Again, in my experience, that cost is zero: the meaning of an I7
program is no less clear than that of a C# or Pascal program. In fact,
on a third level--the one on which IF authoring is done, with actions
leading to various events and responses with various levels of
specificity for different situations--it seems even more clear.
But I suppose my experience could just be more evidence for my
previously mentioned theory.
vw. e. coyote, super genius
Chephren
steve....@gmail.com wrote:
> Chephren wrote:
> > There is little point
> > in arguing whether traditional languages or I7 is easier for
> > programming.
>
> I disagree. It's a really useful discussion for future systems design.
> One of the major goals of I7 was to produce this discussion.
>
Actually, I agree with this. Certainly making and testing hypotheses is
important. I guess what I mean to say is we shouldn't draw any firm
conclusions in the absence of empirical evidence for them.
> > Rather, we should have an empirical survey of people's
> > experiences of the different paradigms, and from there draw an
> > explanation.
>
> Of course I agree that the utility of the system is the main question,
> but I expect that the utility or usability of the system can be
> confused with its used-ness, and I doubt there's a way to distinguish,
> by survey, between frequency-of-use and value.
>
Naturally such a survey would have to cover the possibility of such
ambiguity. For experienced users of more traditional languages this
would be less of a problem, because they already have extensive
experience with which to compare it with. I see how it would be more
problematic for non-programmers though, who had perhaps never given
traditional programming a fair trial. Perhaps more suitable would be
an experiment, in which non-coders are given equal time with each
paradigm to implement a solution to a problem. That way we could
statistically compare the results.
> That the "Inform" label is attached to I7 virtually assures its success
> as a widely used language. (I congratulate Graham for taking this
> assured success and doing something interesting with it.) The used-ness
> is beyond question, and it's worth inquiring the utility.
>
> That said, I believe that if you take a survey right now, most
> experienced IF writers will express mixed feelings on the overall
> benefit of NL programming.
>
> Most will say that the main benefit of I7 is the relational logic and
> the rule-orientation, not the NL gloss.
>
That's what I would find interesting to know. Experienced IF writers,
does NL aid or impede the (admitted?) benefits of relational logic and
rule-orientation.
> > So what are the facts? What percentage of people found I7 facilitates
> > their IF programming, and what percentage that it inhibits it? This is
> > a question to programmers and non-programmers alike.
>
> To draw a theory from some average of disparate personal experiences
> means to disqualify certain useful lines of inquiry from the beginning.
> It's another approach to systems theory, I suppose, but I don't see any
> benefit to counterbalance the obvious loss of critical thought.
Yeah, just the average wouldn't tell us much I guess. My questions
were mainly just for starters. What I want is a theory drawn from
people's detailed responses, that can explain those responses, and
indicate the relative benefits of the different elements: be it the
IDE, rule-orientation, NL, or even (if it exists) the inform 'celebrity
factor'.
What I see as a danger in your approach, is arriving at conclusions
about how people will experience I7's features, irrespective of
people's actual experiences! It might be taken as condescending (not
to mention completely ad hoc) to dismiss those experiences that
conflict with your pre-held theory as a kind of false-consciouness
(people don't realise how frustrating I7 is for them, because they're
too infatuated with it).
Chephren
David Tanguay wrote:
> Chephren wrote:
> > Part of the contention, I think, is that Steve's arguments seem to
> > conflict with people's experiences. Steve is saying that NL as it is
> > employed by I7 is more difficult than normal programming (even for the
> > domain of IF), but others argue they have found the approach makes IF
> > development easiar.
> >
> > So what are the facts? What percentage of people found I7 facilitates
> > their IF programming, and what percentage that it inhibits it? This is
> > a question to programmers and non-programmers alike.
>
> To know the facts, we would first have to separate out the various changes
> of I7. E.g., Steve has been arguing that NL is bad. Suppose he's right: the
> declarative nature (and IDE, whatever else) may be such pluses as to
> overcome the NL drag.
>
Yeah, you're right here.
> The only way to begin to see whether NL is a plus or minus is to first make
> a formal / mathematical / traditional programming (whatever you call it,
> a BNF grammar thingy) syntax for the underlying I7 system, and then see how
> the two compare.
>
Well, this would settle the matter more conclusively. Though I think
we can start to get some indication from people's responses. A
thoughtful person should be able to relatively weigh the benefits of
the different aspects, simply by comparing how much time they are spent
frustrated by the IDE not doing what they expect, trying to phrase
their thinking in terms of rule&relational logic, and playing guess the
NL syntax.
> In another way, the NL seems to be a big win. It may not mean much to
> experienced programmers, but (from the various postings) it seems to have
> created a comfort level for non-programmers. Even if it turns out to be a
> false comfort in the longer run, it gets them over the initial inertial
> resistance to trying something new and difficult.
Definitely, I suspect a large segment of the population have an inbuilt
negative reaction of anything resembling maths or formal symbolism.
xexagon
> In another way, the NL seems to be a big win. It may not mean much to
> experienced programmers, but (from the various postings) it seems to have
> created a comfort level for non-programmers. Even if it turns out to be a
> false comfort in the longer run, it gets them over the initial inertial
> resistance to trying something new and difficult.
Speaking from my own experience, this is exactly the case. For those
of us with zero or minimal (e.g. ZX Spectrum BASIC circa 1984)
programing knowledge, it takes a few minutes to write a playable game
with a few rooms, objects and characters. There is a big practical
advantage here: I wonder how many people downloaded Inform 6 and then
didn't bother doing anything with it, turned off by using lots of '{'s,
and the compilation process?
I just wonder what is being done to promote I7 to a wider audience?
People seem to be nostalgically stumbling upon it, rather than having
it shown to them.
slate...@gmail.com
not reading all the documentation) I'll say this. I've done programming
of various sorts (mostly in a Lisp derivative) for two or three years
as a hobby. I learned a good bit of I6, but haven't done much with it
for about six months. I've still got my printed copy of the DM4 lying
around somewhere.
Just picking up I7 and playing around with it, I've been easily able to
do a good bit. On the other hand, figuring out exactly what phrase to
use, or why there's no easy way to do switches, or what exact things I
need to have a conversation between two NPCs going on in the background
can be a bit of a pain. In fact, given a week or so with a half-decent
I6 IDE (are there any still out there?) and the DM4 I could be at the
same point in I6 proficiency that I am in I7 proficiency, and I
wouldn't need to think so hard about how to phrase, "change the
fullness of the drink to the fullness after the fullness of the drink."
I can work in I7, and it's easy to do a lot of things. On the other
hand, I think I could be more productive with I6 and something that
does proper syntax coloring for it.
vaporware
> Just picking up I7 and playing around with it, I've been easily able to
> do a good bit. On the other hand, figuring out exactly what phrase to
> use, or why there's no easy way to do switches, or what exact things I
> need to have a conversation between two NPCs going on in the background
> can be a bit of a pain. In fact, given a week or so with a half-decent
> I6 IDE (are there any still out there?) and the DM4 I could be at the
> same point in I6 proficiency that I am in I7 proficiency, and I
> wouldn't need to think so hard about how to phrase, "change the
> fullness of the drink to the fullness after the fullness of the drink."
>
> I can work in I7, and it's easy to do a lot of things. On the other
> hand, I think I could be more productive with I6 and something that
> does proper syntax coloring for it.
The Mac version of I7 does syntax coloring for I6 projects (and I6 code
embedded in I7 projects). Hopefully this feature will be added to the
Windows version at some point.
What would really be nice is syntax completion, especially for those
long phrases and names in I7.
vw
na...@natecull.org
John Prevost wrote:
> na...@natecull.org wrote:
> > and still ugly, owing to lack of nested conditionals. I think a custom
> > Micro-Planner like language with its own pattern-matching semantics
> > (and real functions) is called for.
>
> I've been thinking a bit about a logical programming language that
> supports syntax extension as a basic feature. (Generally, for
> mixfix-style relational operators.) It could have a prolog-like syntax
> to start, but be extended to allow more natural declarations.
>
> For example:
>
> {X is a Y} := exists(X), is_kind(Y), has_kind(X,Y).
In my tinkering with Prolog, I'm more and more coming to the conclusion
that Prolog syntax as it stands is a bastardisation of Lisp, and were I
to implement a Prolog evaluator it would be using mostly standard
S-expression notation. (Possibly with two kinds of brackets, to
distinguish forms and lists, but I'm not even sure about that). The
main reason for this is that it would be a lot simpler to write a lexer
and parser for S-expressions than for Prolog, but also S-expressions
just look nicer to read. Particularly since you can embed
pseudo-English inside a list, like so:
"this is a raw English sentence to be parsed, as a string"
(this is a similar string just tokenised into Lisp atoms)
(this is (a similar string just tokenised into Lisp atoms))
and start marking it up with grammatical/semantic markers
-- that last one has been turned into 'subject predicate object' form
just by adding brackets.
((statement (X is a Y))
if ((exists X) (is-a-kind Y) (has-kind Y X)))
... is a nearly pure S-expression Prolog translation of your desired
language above. (I always read ':-' as 'if' mentally anyway).
Simple to write a parser for, nice and clean to read, and we can make
it pretty darn close to English if we just keep incrementally adding
smarts to the compiler or initial load-phase inferencing rules. (Even
English has brackets in it, after all.. it's sometimes useful to be
able to say '((pretty little) girls school)').
>
> The other thought I had is the idea of an "implication" for
> compile-time statements. In Prolog, you can write something like the
> following if you want three things to become true when one thing is
> true:
>
> exists(X) :- is_a(X,Y).
> exists(Y) :- is_a(X,Y).
> has_kind(X,Y) :- is_a(X,Y).
Yes, that would be very neat. Hewitt's PLANNER had both 'antecedents'
and 'consequents' as primitives, so it had an implication mechanism as
well as Horn clause type things. Presumably there are performance
improvements you get if you restrict the evaluator to only doing Horn
clauses at runtime.
What I'm thinking about is rather than a compiler, having a load-time
bind phase, where the runtime would examine the code and generate a
bunch of assertions; generating Horn clauses from implications would
seem to be fairly easy at this point.
We could spin this off into a compiler, or an instrumented debugging
runtime, if we wanted to keep the end-user runtime small, but I rather
like the idea of getting out of the 'the game will be running on a very
small machine' box and get back to the wide open dynamic research lab
environment of the 1970s. All sorts of other interesting aspects open
up, too, with logic programming, and especially if we drop a compile
phase - we can generating inferences about all sorts of things, both at
load and at runtime - run validation checks to see if there are logical
contradictions in the source code, dynamically achange the nature of
the story, add new verbs on the fly, etc.
> The main thing I haven't put a lot of though into yet is how to handle
> precedence of rules. There's a kind of modal logic there (statements
> have different kinds of trueness: always true, usually true, used to be
> true...)--setting a default "X smells of nothing :- X is a thing" and
> then a specific rule "X smells of sweetness :- X is a flower" would
> want to override. But in Prolog, of course, you get the answers in the
> order that the search finds them. It makes sense there--you're getting
> back *all* of the answers. But here, you sometimes want one preferred
> answer. (Likewise with parsing: parsing in a logical language is
> suprisingly easy to model--but will give you back all of the possible
> parse trees, whereas we'd want to choose one preferred tree.)
Yes, that's a big one, and I don't quite know how to approach it. I
think Zarf is wrestling with the same problem: what's a suitably
general mechanism for setting and adjusting rule precedence?
Prolog allows metaprogramming, so it's probably easy enough to wrap a
Prolog-like rule mechanism inside a construct that adds rule labels,
guard clauses, type checking, decent nested conditionals, maybe
'before' or 'after' directives... and with sufficient introspection
inside the guard clauses the compiler/loader can probably work out a
good general rule ordering... but that's only a very general beginning.
An interesting thing I've found: I'm wondering whether 'IS-A' is even
required, since 'IS' (for dynamic attributes, like I7's adjectives)
plus dynamic inferences could maybe do everything a hierarchical type
system can. But again, how to define the order of inferences is the
tricky bit.
steve....@gmail.com
> In my tinkering with Prolog, I'm more and more coming to the conclusion
Do you know of anything in the CS literature which would corroborate
this conclusion, or is this impression perhaps novel?
Kevin Forchione
news:1153099571.8...@s13g2000cwa.googlegroups.com...
>
> John Prevost wrote:
>> na...@natecull.org wrote:
>> > and still ugly, owing to lack of nested conditionals. I think a custom
>> > Micro-Planner like language with its own pattern-matching semantics
>> > (and real functions) is called for.
>>
>> I've been thinking a bit about a logical programming language that
>> supports syntax extension as a basic feature. (Generally, for
>> mixfix-style relational operators.) It could have a prolog-like syntax
>> to start, but be extended to allow more natural declarations.
>>
>> For example:
>>
>> {X is a Y} := exists(X), is_kind(Y), has_kind(X,Y).
>
> In my tinkering with Prolog, I'm more and more coming to the conclusion
> that Prolog syntax as it stands is a bastardisation of Lisp, and were I
> to implement a Prolog evaluator it would be using mostly standard
> S-expression notation. (Possibly with two kinds of brackets, to
> distinguish forms and lists, but I'm not even sure about that). The
> main reason for this is that it would be a lot simpler to write a lexer
> and parser for S-expressions than for Prolog, but also S-expressions
> just look nicer to read. Particularly since you can embed
> pseudo-English inside a list, like so:
Heh! I've been developing something like this myself (calling it TPL: Tads
Programming Logic Language). It's rudimentary prolog with a Lisp-like syntax
in an interpreted environment.
--Kevin
na...@natecull.org
I highly doubt the impression is novel - most of the old Lisp-heads
such as Paul Graham and many of the denizens of Ward's Wiki wax on at
great length about the delights of S-expression syntax.
The heritage of Prolog from various Lisp-based research logic languages
and theorem provers via Micro-Planner and Planner is pretty well
documented. Are you seriously contesting this?
na...@natecull.org
Kevin Forchione wrote:
> Heh! I've been developing something like this myself (calling it TPL: Tads
> Programming Logic Language). It's rudimentary prolog with a Lisp-like syntax
> in an interpreted environment.
>
> --Kevin
Ooh! Do you have any downloadables? I'd be very interested in sharing
notes. Hosting something like that on T3 is probably slightly easier
than writing a runtime for Glulx, since I'm guessing there would be
garbage collection for free (I'm not even thinking about Zcode at this
point)... though I've been vaguely wondering about the possibilities of
a cross-platform logic environment. But if I'm going to reinvent the
square wheel anyway, it doesn't really matter what VM I use, as long as
it has Windows, Linux and Mac support and a Glk interface so I can run
it with something nice like Gargoyle.
John Prevost
na...@natecull.org wrote:
> An interesting thing I've found: I'm wondering whether 'IS-A' is even
> required, since 'IS' (for dynamic attributes, like I7's adjectives)
> plus dynamic inferences could maybe do everything a hierarchical type
> system can. But again, how to define the order of inferences is the
> tricky bit.
I agree. Classes are something generally not needed as a built-in
concept in a logical language, since they're really just a sort of
implication:
syntax {X is a kind of Y}.
X is a kind of Z :- X is a kind of Y, Y is a kind of Z.
syntax {X is a Y}.
X is a Y :- kind(X,Y).
X is a Y :- X is a Z, Z is a kind of Y.
A flower is a kind of thing.
A rose is a kind of flower.
syntax {X smells of Y}.
X smells of nothing :- X is a thing.
X smells of spring :- X is a flower.
X smells of sweetness :- X is a rose.
Again, the problem here is deciding that the "preferred" scent of the
rose is "sweetness". I have some ideas. For example: if we say that
we'll use normal procedural/functional syntax for "behavior", and the
above syntax only for queries and rules, then we don't have to worry so
much about being able to express logic or sequencing using horn
clauses. And given that, perhaps just saying "The values returned for
a query are given based on a breadth-first search with the last
definition examined first."
In Prolog, you generally use depth first search, because it allows you
to control the order in which values are found in a manner that's
convenient for predicting execution order. This is important when you
are expressing loops and conditionals in terms of horn clauses, but not
so useful if you have other means to express that sort of thing. DFS
means "first exhaust the first case, then the second case, and so on."
But if we use breadth first search, that changes things. Instead of
"exhaust the first case before considering the second", we have "follow
all cases simultaneously", and we give as our first result the value
with the "shortest proof".
In the above, consider:
The joyfulness tea rose is a rose.
The nadesico is a flower.
The nadesico smells of X?
The joyfulness tea rose smells of Y?
To solve the first query (handwavingly):
The nadesico smells of X?
The nadesico smells of nothing :- The nadesico is a thing (3)
The nadesico is a thing :- The nadesico is a Z, Z is a kind of
thing.
The nadesico is a flower
A flower is a kind of thing.
The nadesico smells of spring :- The nadesico is a flower (2)
The nadesico is a flower.
The nadesico smells of sweetness :- The nadesico is a rose (X)
no applicable rules
And the second follows similarly:
The joyfulness tea rose smells of Y?
The joyfulness tea rose smells of nothing :- The joyfulness tea rose
is a thing (4)
The JTR is a thing :- The JTR is a Z, Z is a kind of thing.
The JTR is a rose.
A rose is a kind of thing :- A rose is a kind of W, a W is a kind
of thing.
A rose is a kind of flower.
A flower is a kind of thing.
The JTR smells of spring :- The JTR is a flower (3)
The JTR is a flower :- The JTR is a Z, Z is a kind of flower.
The JTR is a rose.
A rose is a kind of flower.
The JTR smells of sweetness :- The JTR is a rose (2)
The JTR is a rose.
The above isn't very precise, but it shows the idea. In each case, the
shortest path (and therefore the first proof found by a BFS) is the
"most specific" to the statement in question. In order to say that the
joyfulness tea rose smells of nothing, you must first discover that it
smells of sweetness (because it is a rose), and then that it smells of
spring (because all roses are flowers), and then that it smells of
nothing (because all flowers are things.) In the case that two rules
of the same "depth" conflict, the later definition is looked at first.
With this model, it seems reasonable to then provide different searches
that can be performed. There's the "find me the preferred value of all
of the variables in this statement?" kind of search, which is great for
finding "the value of X for Y", the "is this true for anything?"
search, which is really just the above ignoring the variables, and the
"give me the preferred value, and then let me get other values as well"
kind, which is good for some properties. (i.e. in the above, we assume
every thing only smells of one thing. Instead, we could say that we
care about *all* of the smells something has--adding perfume to a thing
might allow you to then detect all of the scents.)
This doesn't cover everything--for example, how would you define a
scent of gasoline that overrides any other scent? (If a rose were
doused in gasoline, I doubt very much it would smell as sweet.) And
it's unclear whether it provides all the generality you'd want for
various things like a rule system, but it's a start.
John.
steve....@gmail.com
> > Do you know of anything in the CS literature which would corroborate
> > this conclusion, or is this impression perhaps novel?
>
> I highly doubt the impression is novel - most of the old Lisp-heads
> such as Paul Graham and many of the denizens of Ward's Wiki wax on at
> great length about the delights of S-expression syntax.
>
> The heritage of Prolog from various Lisp-based research logic languages
> and theorem provers via Micro-Planner and Planner is pretty well
> documented.
I've always vaguely thought of Prolog as the resolution algorithm, with
the syntax being arbitrary. I guess this is the normal conception, as
superficial syntax is the only real difference between the various
Prolog dialects.
I think you're saying about the same thing on the relationship between
Lisp and S-expression syntax. I hadn't thought of the various Prolog
syntaxes as derivative of Lisp's S-expression syntax, but I can see
what you mean.
I like S-expression also. For writing a standard IF player-interface
parser, have you looked at the TADS 3 syntax for grammar rules? That's
custom-designed for the purpose. I'd be happy to give you a quick
rundown if you haven't looked at it (and perhaps you'd prefer not to
get your hands all greasy).
> Are you seriously contesting this?
I don't see why you imply I'm arguing against the answer, merely by
asking a question. I am not the auto-arguer you seem to take me for.
na...@natecull.org
> But if we use breadth first search, that changes things. Instead of
> "exhaust the first case before considering the second", we have "follow
> all cases simultaneously", and we give as our first result the value
> with the "shortest proof".
Intriguing. That's exactly the search method I use in RAP and
Planner/I7, and for the same reason. I sort of stumbled on it, looking
at the test case of path-finding through rooms with locked doors and
fetchable keys. It seemed fairly robust in that domain, but I hadn't so
far considered the implications of generalising it further for
predicate search.
> This doesn't cover everything--for example, how would you define a
> scent of gasoline that overrides any other scent? (If a rose were
> doused in gasoline, I doubt very much it would smell as sweet.) And
> it's unclear whether it provides all the generality you'd want for
> various things like a rule system, but it's a start.
Yeah, still not sure about rules. It seems that they tend to have very
simple and direct general-case statements that are overridden by more
complicated special-cases with possibly longer proofs.
Most humans tell the truth.
Most Cretans are liars.
All people are humans.
A person is a Cretan if they were born on Crete or have resided in
Crete for more than 20 years.
Mega-Socrates is a human born in Gondwanaland who has been living in
Crete for 21 years.
Does Mega-Socrates tell the truth?
or an IF problem:
A room is usually lighted.
When the cloak of darkness is worn, a room is dark.
has_attribute(X, lighted) :- has_attribute(X, room, true).
hasnt_attribute(X, lighted) :- has_relation(cloak, worn-by, player),
has_relation(player, located-in, X).
has_attribute(myroom, room).
has_relation(cloak, worn-by, player).
has_relation(player, located-in, myroom).
Not sure how a breadth-first solver would pick that one up any better
than a depth-first. Other than manually tagging rules with precedence
orderings:
normal_lighting_rule: has_attribute(X, lighted) :- has_attribute(X,
room, true).
cloak_lighting_rule: hasnt_attribute(X, lighted) :- has_relation(cloak,
worn-by, player), has_relation(player, located-in, X).
overrides(cloak_lighting_rule,normal_lighting_rule)
And then the solver just checks for any 'overrides' predicates before
it tests any rules, and recursively explores the overriding rule first,
then the overridden rule.
But that seems like it would get awkward for the programmer to
maintain.
na...@natecull.org
steve....@gmail.com wrote:
> I've always vaguely thought of Prolog as the resolution algorithm, with
> the syntax being arbitrary. I guess this is the normal conception, as
> superficial syntax is the only real difference between the various
> Prolog dialects.
Well, resolution plus data model and semantics, more than syntax. The
internals of Prolog feel very Lisp-like, in that you can pull things
apart recursively into heads and tails, and even though forms aren't
quite like Lisp lists, they feel like they were abstracted from lists
and then sort of turned inside out, so that Prolog lists end up
implemented as forms rather than the other way around.
> I like S-expression also. For writing a standard IF player-interface
> parser, have you looked at the TADS 3 syntax for grammar rules? That's
> custom-designed for the purpose. I'd be happy to give you a quick
> rundown if you haven't looked at it (and perhaps you'd prefer not to
> get your hands all greasy).
I've glanced at it. The sheer size of the TADS3 system plus its lack of
documentation is what keeps throwing me.
> > Are you seriously contesting this?
>
> I don't see why you imply I'm arguing against the answer, merely by
> asking a question. I am not the auto-arguer you seem to take me for.
Well, it seemed a very strange kind of question to ask if it wasn't
rhetorical, particularly coming from someone who apparently knows
Prolog. But I suppose textbooks or programming classes perhaps don't
teach the history of languages? Most of what I know about AI and CS I
have learned quite recently by reading Wikipedia and Ward's Wiki and
those sources seem to give a lot more of the background and interplay
between research ideas than I ever learned in class, which I find much
more fascinating and easier to remember than just the rote facts of
syntax and grammar.
Richard Bos
> steve....@gmail.com wrote:
> > If we say that the I7 version is easier to read, we probably mean that
> > it's easier to figure out what the writer is trying to do -- regardless
> > of whether or not it works. But if you're reading this to understand
> > what the code is actually doing, you have to mentally parse each
> > statement the same way (not exactly the same, but the same basic mental
> > process),
>
> Most of us are already used to that mental process every day, because
> reading Inform 7 code is much like reading English.
Erm... no, it isn't.
> Some terms have special meanings, but it's no more awkward than reading
> a trade magazine, encyclopedia, or newsgroup post.
An encyclopedia does not have begin... repeat in it. In a newsgroup
post, "now everything in the room is green" is an observation, and does
not change the colour of anything.
Richard
vaporware
I'm not sure what your point is. An article in a medical journal
doesn't have "scored 4 RBIs and 6 home runs" in it, and an article in a
children's magazine doesn't have "hiked interest rates" in it. "Flop
the nuts and push it all in" means something quite different in a poker
strategy guide than it does in Penthouse Forum.
Does that mean the skills you'd use to read a sports article, a medical
journal, a children's magazine, an economic report, a poker book, and a
dirty story are entirely different? Or does it just mean specific
fields use specific jargon?
"Now everything in the room is green" is essentially jargon for "change
everything in the room to green", just as "while (C) begin; (S); end
while" is essentially jargon for "as long as (C) is true, do (S)". If
you've ever read a recipe or a set of instructions, you're already
familiar with those concepts; I7 just uses specific phrases to convey
them.
vw
Kevin Forchione
news:44c003e9...@news.xs4all.nl...
<snip>
>In a newsgroup
> post, "now everything in the room is green" is an observation, and does
> not change the colour of anything.
Oh... that must be what I've been doing wrong. Observation is not causation.
Bugger.
--Kevin
Richard Bos
> Richard Bos wrote:
> > "vaporware" <jmc...@gmail.com> wrote:
> >
> > > Some terms have special meanings, but it's no more awkward than reading
> > > a trade magazine, encyclopedia, or newsgroup post.
> >
> > An encyclopedia does not have begin... repeat in it. In a newsgroup
> > post, "now everything in the room is green" is an observation, and does
> > not change the colour of anything.
>
> I'm not sure what your point is. An article in a medical journal
> doesn't have "scored 4 RBIs and 6 home runs" in it, and an article in a
> children's magazine doesn't have "hiked interest rates" in it.
No, but they all use normal English grammar, with changes in vocabulary
alone. Inform does not. It's not English; it looks like it
superficially, but it's a different language altogether, and an entirely
more artificial one, at that.
Richard
vaporware
I must disagree. I don't think there are any phrases in I7 that have a
meaning other than their common English meaning. Even the most unusual
I7 code is just a combination of the type of writing used in math
classes, how-to books, and recipes. Do you have any examples of Inform
code that can't be understood by a native English speaker with specific
knowledge of IF terminology?
vw
Neil Cerutti
> Speaking from my own experience, this is exactly the case. For
> those of us with zero or minimal (e.g. ZX Spectrum BASIC circa
> 1984) programing knowledge, it takes a few minutes to write a
> playable game with a few rooms, objects and characters. There
> is a big practical advantage here: I wonder how many people
> downloaded Inform 6 and then didn't bother doing anything with
> it, turned off by using lots of '{'s, and the compilation
> process?
One of the most noticable improvements in Inform 7's latest
version is that the most minimal game is much, much easier to
compose and get working.
"Snort" by Neil Cerutti.
The nasal passages is a room.
That's a complete game, and it runs with the press of one button.
In Inform 6, unfriendly looking boilerplate is necessary, enough
so that even an experienced Inform coder like me had to look at a
template after very much time without creating a new project. In
addition, composing the correct command to compile was a pain in
the hiney, particularly for a person who'd never used a
command-line compiler before.
Graham and company have knocked down an enormous barrier to entry
just with thos two things. Whether or not natural language
knocks down another big barrier is, I guess, what's under
discussion.
But I think the code above is good evidence that it does. Is
there another way to write the above that's quite as nice? I
can't think of one.
> I just wonder what is being done to promote I7 to a wider
> audience? People seem to be nostalgically stumbling upon it,
> rather than having it shown to them.
Nothing, that I'm aware of. I think major promotion, if that's
even necessary, should wait for Inform 7's first major, non-beta,
version.
--
Neil Cerutti
The outreach committee has enlisted 25 visitors to make calls on
people who are not afflicted with any church. --Church Bulletin
Blooper
James Jolley
I can say personally that I7 has changed everything regarding IF for me.
I tried I6 and read and re-read the DM4 and hated the clunky compiler
and things. Now, it's just so much easier to get on with it and start
projects and experiment with designing IF.
As to getting it out to other audiences, I can only speak for the fact
that my dad indeed interested in learning how to write IF and I have
sent him inform 7 to try.
All the best
-James-
----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms at!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----
Gene Wirchenko
[snip]
>Yes, in the former sense; and in this sense you are reading English,
>and not computer code at all. But not in the latter sense, when you're
>understanding what the code is doing. That level obviously does not
>exist when you're reading regular English. (You don't bench-check
>English, for instance.)
I do. It is called proofreading.
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Gene Wirchenko
[snip]
>Well, this would settle the matter more conclusively. Though I think
>we can start to get some indication from people's responses. A
>thoughtful person should be able to relatively weigh the benefits of
>the different aspects, simply by comparing how much time they are spent
>frustrated by the IDE not doing what they expect, trying to phrase
>their thinking in terms of rule&relational logic, and playing guess the
>NL syntax.
There is also thinking that you know the syntax. I see a false
friend of English-like syntax. NL sounds interesting, but then I have
read so many posts about special cases that it does not look so easy
after all. It may be cloaked as appearing easy, because it is so
similar to English.
Gene Wirchenko
[snip]
>In another way, the NL seems to be a big win. It may not mean much to
>experienced programmers, but (from the various postings) it seems to have
>created a comfort level for non-programmers. Even if it turns out to be a
>false comfort in the longer run, it gets them over the initial inertial
>resistance to trying something new and difficult.
That same logic can be used to support using ADRIFT.
Kevin Forchione
news:v04qc2hqva6seikqk...@4ax.com...
> There is also thinking that you know the syntax. I see a false
> friend of English-like syntax. NL sounds interesting, but then I have
> read so many posts about special cases that it does not look so easy
> after all. It may be cloaked as appearing easy, because it is so
> similar to English.
That's been Steve Breslin's stance from the beginning. If the poor bugger
could stay clear of needless squables involving ad hominen arguments this
might have been better articulated. Still, it remains to be seen whether
this proves to be any more a liability to the game author than having to
learn a more conventional and more obviously symbolic programming language.
--Kevin
David Tanguay
> David Tanguay <datan...@sentex.Xca> wrote:
>
> [snip]
>
>>In another way, the NL seems to be a big win. It may not mean much to
>>experienced programmers, but (from the various postings) it seems to have
>>created a comfort level for non-programmers. Even if it turns out to be a
>>false comfort in the longer run, it gets them over the initial inertial
>>resistance to trying something new and difficult.
>
>
> That same logic can be used to support using ADRIFT.
Yes, at least to start. Hasn't Adrift been successful in getting lots of
people to try creating IF? Adrift's shortcoming seems to be (I'm going on
newsgroup comments) that once you come to the end of what it does easily,
things then get very difficult -- it doesn't scale well as programs become
more complex. Hopefully I7 can do a better job of handling more complex
computation, of not making it too much more difficult to implement than it
has to be.
Ideally, we would like to have both entry level simplicity and expert level
flexibility, but if we can't, if there's some tradeoff at some point, then it
becomes a matter of finding the right balance. Adrift may have missed that
balance, but that doesn't mean there isn't a better one than I6/TADS/etc.
--
David Tanguay Kitchener, Ontario
Gene Wirchenko
IME, learning is easier than unlearning. The problem with
unlearning is that first, you have to figure out that you have to
unlearn. That may be hidden in assumptions that you do not ordinarily
think about. It is rather easier to know that you do not know.