Am I really the only person who doesn't get I7

Here is the story:

The Fruzzle is an animal.

The description of the Fruzzle is "An animal about the size of a big cat. It is covered in soft lavender fur. It has a long pointed muzzle. The dark band of fur across it’s eyes makes it look like it is wearing a mask. It’s long furry tail is covered in pumpkin colored splotches. "

The Fruzzle has a number called fear.
The fear of the Fruzzle is 0.

The large nut is a thing. “A heavy brown nut about the size of a couple of golf balls”

The forest is a room.

The Fruzzle is in the Forest.

Every Turn when the player is in the Forest:
	say "fear is [the fear of the Fruzzle]."; 
	Increment fear of the Fruzzle.

This story works just like you would expect it to. The fear is displayed and then incremented each turn.

Let’s build on this working example. Now we are going to add some behavior changes for the Fruzzle. We let it show it’s agitation when it’s fear is equal to three.

The forest is a room.

The Fruzzle is in the Forest.

Every Turn when the player is in the Forest:
	say "fear is [the fear of the Fruzzle]."; 
	If the fear of the Fruzzle > 3,
		Say "The Fruzzle begins to sway from side to side.  It makes a funny noise that sounds like a warning.";
	Increment fear of the Fruzzle.

Success! This story works just like you would expect. The fear is displayed and incremented each turn. Once fear passes 3 we get the new “say”.

So now we would like to let the Fruzzle escalate it’s response as it’s fear rises even higher. So when it’s fear passes 5 it will give us a new more aggressive response.

The forest is a room.

The Fruzzle is in the Forest.

Every Turn when the player is in the Forest:
	say "fear is [the fear of the Fruzzle]."; 
	If the fear of the Fruzzle > 5,
		Say "The Fruzzle has become quite agitated.  It stands on it's back legs, with it's fur on end. It is now hissing and showing it's formidable fangs.";
	else If the fear of the Fruzzle > 3,
		Say "The Fruzzle begins to sway from side to side.  It makes a funny noise that sounds like a warning.";
	Increment fear of the Fruzzle.

But wait a minute, we now find that there is a translation error:

This is the report produced by Inform 7 (build 6E72) on its most recent run through:

Problem. You wrote ‘else If the fear of the Fruzzle > 3, Say “The Fruzzle begins to sway from si […] noise that sounds like a warning.”’ : but structural phrases like ‘if’, ‘repeat’, ‘while’ or ‘otherwise’ can’t be used as part of the abbreviated form of other structural phrases, so for instance ‘if in darkness, repeat with X running through rooms’ is not allowed because the ‘repeat’ is too important a phrase to be put at the end of a simple ‘if’ like this. Instead, the ‘if’ must be written out in full, so for instance ‘if in darkness begin; repeat … begin; …; end repeat; end if;’ would be fine.
See the manual: 11.8 > Otherwise

This rule tells us we have pull if out on it’s own. By the way, 11.8 makes no mention of this rule. The rule also says that repeat is too important to be put in a simple if.

Small rant follows:
In other languages, I believe the if structure allows us to write anything in a block that can go in a block.
If (condition)
“true” block
else
“false” block.

We can say things like this (I don’t know why anyone would want to)
read record
If (condition)
begin
repeat while not end of file
begin
if record-key is odd
begin
If first time
begin
open discard file
end
Write record to discard file
end
read record
end

end
else
begin
……
end

So much for the rant. To get back on track, I pulled the If out of the “Every turn” and gave it its own full block structure. Revised code now reads:

The forest is a room.

The Fruzzle is in the Forest.

Every Turn when the player is in the Forest:
	say "fear is [the fear of the Fruzzle]."; 
	Increment fear of the Fruzzle.

If the fear of the Fruzzle >5 begin;
	Say "The Fruzzle has become quite agitated.  It stands on it's back legs, with it's fur on end. It is now hissing and showing it's formidable fangs.";
end if,
else
	Say "The Fruzzle begins to sway from side to side.  It makes a funny noise that sounds like a warning."

Yup now I have a new set of translation errors:

This is the report produced by Inform 7 (build 6E72) on its most recent run through:

Problem. You wrote ‘If the fear of the Fruzzle >5 begin’ : but I can’t find a verb that I know how to deal with. This looks like an ‘if’ phrase which has slipped its moorings, so I am ignoring it. (‘If’ phrases, like all other such instructions, belong inside definitions of rules or phrases - not as sentences which have no context. Maybe a full stop was accidentally used instead of semicolon, so that you inadvertently ended the last rule early?)
See the manual: 11.6 > If

Problem. You wrote ‘Say “The Fruzzle has become quite agita […] and showing it’s formidable fangs.”’ : but I can’t find a verb here that I know how to deal with, so I am ignoring this sentence altogether.
See the manual: 2.17 > Review of Chapter 2: The Source Text

Problem. You wrote ‘end if, else Say “The Fruzzle begins to sway from si […] noise that sounds like a warning.”’ : but I can’t find a verb here that I know how to deal with, so I am ignoring this sentence altogether. (I notice there’s a comma here, which is sometimes used to abbreviate rules which would normally be written with a colon - for instance, ‘Before taking: say “You draw breath.”’ can be abbreviated to ‘Before taking, say…’ - but that’s only allowed for Before, Instead and After rules. I mention all this in case you meant this sentence as a rule in some rulebook, but used a comma where there should have been a colon ‘:’?

And what do you think the first error is ? An if can’t exist unless it is inside another structure. So you go to the page 11.6 to find out what to do. It is entirely silent on the point. In fact all of the examples are shown inside of no context.

It looks like I have two rules: one that says I have to put “if” inside of another structure; one that says not to. I am hoping there is some way to evaluate a condition which allows nesting of tests. Anybody know what it is?

Follow up your “if” statements with colons instead of commas.

Thanks for the suggested answer.

Here is the revision

The forest is a room.

The Fruzzle is in the Forest.

Every Turn when the player is in the Forest:
	say "fear is [the fear of the Fruzzle]."; 
	Increment fear of the Fruzzle.

If the fear of the Fruzzle >5:
 begin;
	Say "The Fruzzle has become quite agitated.  It stands on it's back legs, with it's fur on end. It is now hissing and showing it's formidable fangs.";
end if,
else
	Say "The Fruzzle begins to sway from side to side.  It makes a funny noise that sounds like a warning."

Unfortunately, more translation errors.

This is the report produced by Inform 7 (build 6E72) on its most recent run through:

Problem. You wrote ‘If the fear of the Fruzzle >5’ : but the punctuation here ‘:’ makes me think this should be a definition of a phrase and it doesn’t begin as it should, with either ‘To’ (e.g. ‘To flood the riverplain:’), ‘Definition:’, a name for a rule (e.g. ‘This is the devilishly cunning rule:’), ‘At’ plus a time (e.g. ‘At 11:12 PM:’ or ‘At the time when the clock chimes’) or the name of a rulebook, possibly followed by some description of the action or value to apply to (e.g. ‘Instead of taking something:’ or ‘Every turn:’).

See the manual: 18.3 > New rules

You need the “if” bits to be in a block of code that gets triggered at some point; they don’t make any sense to the compiler by themselves. So, since you have your “every turn when the player is the Forest,” you can put it in there. Just don’t end that block after incrementing – use a semicolon instead of a period.

Every Turn when the player is in the Forest:
[tab]say "fear is [the fear of the Fruzzle].";
[tab]Increment fear of the Fruzzle;
[tab]If the fear of the Fruzzle >5:
[tab][tab]Say "The Fruzzle has become quite agitated. It stands on it's back legs, with it's fur on end. It is now hissing and showing it's formidable fangs.";
[tab]else:
[tab][tab]Say "The Fruzzle begins to sway from side to side. It makes a funny noise that sounds like a warning."

Thank you for the suggested solution. Unfortunately, I got more translation errors.

The forest is a room.

The Fruzzle is in the Forest.

Every Turn when the player is in the Forest:
say “fear is [the fear of the Fruzzle].”;
Increment fear of the Fruzzle;
If the fear of the Fruzzle >5:
Say “The Fruzzle has become quite agitated. It stands on it’s back legs, with it’s fur on end. It is now hissing and showing it’s formidable fangs.”;
else:
Say “The Fruzzle begins to sway from side to side. It makes a funny noise that sounds like a warning.”

This is the report produced by Inform 7 (build 6E72) on its most recent run through:

Problem. In the sentence ‘If the fear of the Fruzzle >5 begin’ , I was expecting to read a condition, but instead found some text that I couldn’t understand - ‘fear of the Fruzzle >5’.
I was trying to match this phrase:
if (fear of the fruzzle >5 - a condition):
This was what I found out:
fear of the Fruzzle >5 = something unrecognised

Problem. You wrote ‘else’ : but this is an ‘else’ or ‘otherwise’ with no matching ‘if’ (or ‘unless’), which must be wrong.
See the manual: 11.8 > Otherwise

You need a space between > and 5. (I’m not sure if this is a bug or a feature, but written together Inform seems to consider them as one word which it doesn’t understand.)

Thank you. That fixed the problem.

I am just not sure I am ever going to get the hang of this.

I had a lot of trouble at first, too. But I learned to change my learning style. You can’t learn this the way you learn procedural or purely object-oriented languages. In those cases, I’ve often been able to pick up a new language in just a day or two by reading as narrow a spec as I can, skip the examples, and just remember the ways in which the same concepts and constructs I have already experienced translate to an alternate, fairly narrow syntax rule set. This approach didn’t work for me with Inform 7, because (1) it’s hard to find a narrow, simple language specification, and (2) it has an upside-down approach from most modern languages.

Typically a programming language tries to represent as powerful a range of abilities with the fewest number of syntax rules possible. This allows you to learn the syntax and then use logic + lego-like creativity to get at what the language can do. But this results in a very deep set of dependencies. Often you end up with functions calling functions calling functions calling functions. But they are all functions, so the syntax is still simple. It’s just reading the code that’s complex.

Inform 7 is upside down: it has a very wide vocabulary and syntax set that allows you (it seems – I am still learning) to accomplish things without piling logic on top of logic quite so much. But that means you are much more frequently dependent on some sort of dictionary, at first. You can’t just read the spec – you have to habitualise yourself to the code, more like a real language. So, to that end, I’ve been reading every single example of code that crosses my path, and I try not to move on until I understand what that specific piece of code is doing. And I try not worry about the completeness of my knowledge the way I would learning an OO language where I can sprint for the finish line: I just trust that I will get there.

Like picking up a human language, this learning method requires a lot of trial and error. Actually it also reminds me of learning how to code for the web, with its interlocking languages (HTML, JS, CSS) with different browsers behaviours. I never read the spec for those either: there didn’t seem to be any point. Pretty soon I just realised that Google was my spec and I was never going to know everything about programming for the web. Inform 7 is not quite that bad in that it is still a self-contained system running on one (or two) virtual machines, so I think that eventually if I keep it up I will know everything.

Anyway, that’s just my perspective on it, and how I changed it so that I wouldn’t end up attempting to choke my monitor or something just because I wasn’t learning it the way I usually learn a programming language. YMMV. 8)

Paul.

1 Like

I think you summed it up pretty well, Paul. Some, “regular” languages I learn by reading examples, intuit the very few rules of syntax/grammar/whatchamacallits, and then use a reference book from there. Others, notably Perl, I have to read the manual. I had to read Inform’s manual, and nearly three years later there’s still many corners I’m new to.

In Inform’s defense, it’s easier to use now than it used to be.

1 Like

Writing a game purely for the purpose of learning helps, which is not something I usually do either, but It’s less frustrating getting bogged down correcting your syntax and untangling your wrong assumptions about the way phrases & rules work, when you know that the only reason you are writing this code is so that you can run into these problems: the more the better.

So, I do have a labour of love which I was thinking of porting to Inform 7, but I’m writing a small game first in my spare time: it’s less stressful. 8)

Paul.

I’ve found asking questions on this forum to be a great way of learning Inform.

Ron Newcomb’s “Inform 7 for Programmers” was a big help too.

1 Like

I really appreciate the thought that has gone into this discussion. It has helped me a great deal. I would like to make a point that perhaps only someone who is new can legitimately make.

I7 is an artificial language. It apparently exists to allow a story teller a way to create IF. Somewhere along the way those two points have been lost. What we have now is something, which constrains the player to simple commands - go north, touch the stone, and so on. Meanwhile, the author is confronted with an opaque language protected by byzantine rules.

I agree with you wholeheartedly, languages that have to invoke something that invokes something and so on, are a giant pain. We used to have extremely rich computer programming languages. ALGOL is perhaps the best example. Aside from its left-handed recursion problems, there were any number of ways to express a particular construct. It was a nightmare to learn and debug. Consequently, simpler and more powerful languages took its place.

Over the last 45 years we have seen agreement on three points in computer programming languages. First, any algorithm can be expressed using a very small set of instructions. A thanks goes to Edsger Dijkstra for the birth of Structured Programming. Second, strongly typed languages can implement any algorithm. A thanks given to Wirth and the development of Pascal. Third, procedure and data are interchangeable. A thanks given to Ted Codd for Codd’s Theorem and Jackson for data driven programming. As data structure grew even more complex they evolved into objects. If you had to work through LISP, SIMULA and SmallTalk you have met objects.

Which brings me to the heart of the story teller’s craft. We have character. We have action. We have location. We have conflict and thereby plot. Our stories are abstractions. There is just enough reality in our stories to make them believable. Even when they take place in times and locations which are fanciful.

I believe that means artificial languages, like I7, exist to serve these basic constructs of story telling. At the mechanical level IF is computer programming. We know that small, compact, easily understood artificial languages have won. Perhaps it is time the author should have a small, well defined and straight forward way to create IF.

I think I7 is primarily about writing well structured and logical ways for a player to interact with a world model. It isn’t about constructing narratives. Nick Montfort’s Curveship might be more of what you’re after.

I’m not sure if we need to declare winners and losers here. You’re welcome to create your narrative in TADS if that works better for you.

Personally, I’ve been enjoying I7. Just as with Perl (you probably hate Perl, right?), there are inconsistencies and idiosyncracies, but there’s also a very interesting paradigm in the use of rules and rulebooks. Maybe it will turn out to be an inefficient way of creating text adventures, but I’m enjoying it. I’ve also found much more time for writing and designing than I did when I was trying to create something in I6.

If you’re interested in helping to create a more consistent language with simple primitives, you might want to help Zarf out with his idea for a 100% rule-based language.

Sorry to disappoint. I don’t hate Perl. To me Perl is basically Javascript on steroids for the UNIX shell programmer. Since I have spent some time developing on a LAMP stack, I have a passing understanding of PHP and Perl. Remember, PHP started life as a set of Perl scripts. Also the “P” in LAMP is now also understood to be PHP/Perl/Python.

Larry Wall, Perl’s creator, has two slogans which I really like. TMTOWTDI – There’s more than one way to do it. The second is – easy things should be easy and hard things should be possible. If you know C, C++ or C sharp, then you have the basic feel for Perl. It is a procedural language. It uses brace delimited blocks. It has control structures. It uses subroutines (CPAN is awesome).

It is true that the language supports procedural, object-oriented, and functional styles. Perl doesn’t care which you use or that you jumble them up. This must make implementing Perl a real hair-pulling event. I think somewhere in the Camel Book it says approximately – Perl is a language for getting things done. That is why writing Perl programs is not a hair-pulling event. The language neither forces you into any one style nor does it does it force you to mix styles.

I remember reading some interview with Larry Wall. He made the point that in today’s world the programmer is the most expensive part of software development. So the idea is to make it fast simple and easy for the programmer to get the job done.

That brings me back to a point I made earlier. The story teller should be the focus. I don’t care that I7 supports several different paradigms. My complaint is it forces the story teller to mix paradigms. My recent questions about conditionals (If statements) really points that out. Nesting requires indentation by tabs. It uses a kind-of-block structure that doesn’t have matching begin and end symbols. I7 does not require these structures in other if-statements. In fact it has hidden in one its error messages the statement that I7 regards if as less important than repeat. In procedural languages they are usually on an equal footing. Perhaps, this unusual view deserves more than passing mention in an obscure error message.

Like you I find the rule book structure to be intriguing. Personally, I would like to be able to create “objects” which are completely defined by their innate characteristics and behaviors. As a story teller I would then have the characters, locations and scenery I need. Hopefully, I will learn how to do that along the way.

It is the diversity of the community which keeps a language alive and developing. I hope you see my comments as constructive. I certainly intend them that way. I would like easy things to be easy. The point of I7 should be to get stories told. There is no doubt I just called your baby ugly. You resisted the all to natural desire to order me out of your house. Thank you.

Have you tried any other authoring systems? There are many and they all take more or less different approaches. I don’t think anyone has claimed that Inform would be the best fit for everyone.

That is not true - in fact, at compile time Inform converts tab-indented statements internally into begin…end blocks. If I remember correctly the conditional thread ended with someone suggesting to use the more readable (YMMV) tab-indented form, but that doesn’t mean you couldn’t use begin…end blocks just as well.

This is news to me. Which error message is that?

As for where the error message is about ifs, please look at my first post in this thread.

I think a little bit later you will see other posts about forcing indentation.

Hope this helps.

Ok, if you’re talking about “the ‘repeat’ is too important a phrase to be put at the end of a simple ‘if’ like this”, you’re reading too much into it. It’s not saying that repeat phrases are more important than conditional phrases in general. It’s saying that in this particular example the repeat phrase is too complex for the conditional phrase which is used in its simplified form (with a comma.) The reverse is also true: you can’t use full conditional phrases at the end of a simple repeat phrase.

As for the forced indentation, I’m not seeing it; people are suggesting using the tab-indented form, but no-one is saying that you can’t do it with begin…end blocks (and even if I missed the part where they said that, they were mistaken). The orignal example works fine using begin…end blocks:

Every Turn when the player is in the Forest: say "fear is [the fear of the Fruzzle]."; If the fear of the Fruzzle > 5 begin; Say "The Fruzzle has become quite agitated. It stands on it's back legs, with it's fur on end. It is now hissing and showing it's formidable fangs."; else if the fear of the Fruzzle > 3; Say "The Fruzzle begins to sway from side to side. It makes a funny noise that sounds like a warning."; Increment fear of the Fruzzle; end if.

1 Like

Well, as dannii said, it’s about letting the player interact with a world model, and there’s necessarily a certain tradeoff here. The amount of work you have to do is going to be something like the complexity of your world times the freedom the player has to interact with it. One limiting case is books (aka static fiction, read-only fiction, etc.); the author can make the world as complex as she likes, because the reader can only read what’s on the page. Henry James could write about all sorts of psychological and social complexities (in part) because he didn’t have to make up a lot of stuff about what would have happened if his reader had decided to have Isabel Archer marry [fine, no spoilers] instead. On the other hand, take something like Nethack; you can wander around freely and do all sorts of things, and the world isn’t that much more complex than hitting a bunch of things with weapons or spells or wands or whathaveyou.

In IF, if you’re going to have freeform input, you’re going to need some constraint on the things people can do. Hence things like “go north” or “touch the stone”; you can allow different kinds of commands, but there’s going to have to be some constraint (and some way of letting the player know that you can do that), and you’re going to have to deal with a fairly constrained world model. The challenge is partly in making stories that can be told in this kind of world model, through relatively constrained input from the player. On the other hand, Choose Your Own Adventures (or choice-based narratives or whatever) let you write all kinds of worlds and allow all kinds of actions, because you’re sharply restraining which actions the player can actually take. You can allow “Marry Madame Merle” as a choice at a particular juncture without having to allow the player to try to marry Madame Merle at any other time, or to implement a sequence of actions that lead up to marrying her, etc. There are some IF innovations that allow for more narrativy kinds of interactions without going all the way to CYOA; keyword interfaces, various conversation structures (multiple-choice like Best of Three, keyword-based like the conversations in Blue Lacuna and Walker and Silhouette, deeply implemented topics like Galatea). Though you’ll probably want to look into extensions if you’re interested in those.

I’m not a programmer and don’t really understand a lot of the things you’re saying about algorithms etc., but it seems to me important to understand that I7 is particularly designed for allowing turn-based text input interaction with certain kinds of world models. Given that there’s a lot of structure that you want in there, or available as a default (I think it should be easier to change than it sometimes is, but that’s another story). Expressing any algorithm with a small set of instructions is secondary to that. The, as I understand it, generally sad history of games written in homebrew systems bears this out.

All this said, from what I’ve heard it sounds like TADS3 might be more your cup of tea; it’s more object-oriented and I think more programmery in many ways. This comparison of TADS3 to Inform is a good overview, as I understand it. (TADS3 isn’t very Mac-friendly, though, so I’ve never tried it out.)

(The first part of my post was ninja’d by Juhana, but here it goes anyway):

I think the message you got:

doesn’t mean that “repeat” is more important than “if”; it’s just saying that, if you’re going to have nested conditions or loops you need to explicitly delimit them (with begin/end or tabs or something). Note that ‘if’ is on a par with “repeat” as one of the structural phrases that is not allowed within the abbreviated form of other structural phrases.

Although it doesn’t prevent editing someone else’s Perl program from being hair-pulling… :laughing:

Okay, I get why TMTOWTDI works for you in Perl while I7 is giving you a headache. But as others have pointed out the nesting alternatives in I7, it looks like the real problem is with I7’s documentation - there seems to be a general agreement that it’s wretched, and it’s well illustrated by the frequency of this “well, actually, Inform does do that” sort of comment. Where would Perl be without “Learning Perl” and “Programming Perl”? As a matter of fact, I didn’t get comfortable with Perl until I’d read a third book - Joseph Hall’s “Effective Perl Programming.”

If you consider the compiler’s messages to be part of the documentation, I think it begins to look even more like the language is fine, but the docs need an overhaul.

I’ve been thinking about the indentation issue lately too, and wondering about alternatives. I’d be interested to hear if you had anything to add to this thread:

I certainly appreciate the desire to improve I7 - it’s got a ways to go before it lives up to its promise. But what is it about TADS that makes you think I7 will ever work out better for you?