Error: No expression between brackets '(' and ')' if (())

I think there must be an I6 setting that relates to resources allocated for loops and that I need to set it higher. I am getting the following compiler error:

[code]Translating the Source - Failed
The application ran your source text through the Inform 7 compiler, as usual, and it found no problems translating the source. Something must have gone wrong all the same, because the second stage of the process - using the Inform 6 compiler to turn this translated source into a viable story file - turned up errors. This should not happen. The errors are written out on the Progress tab, but will only make sense to experienced Inform 6 users (if even to them).

The best option now is probably to reword whatever was last changed and to try again. Subsequent attempts will not be affected by the failure of this one, so there is nothing to be gained by restarting the application or the computer. A failed run should never damage the source text, so your work cannot be lost.

If you are using Inform 6 inclusions, these are the most likely culprits. You might be using these without realising it if you are including an extension which contains Inform 6 inclusions in order to work its magic: so if the problem only seems to occur when a particular extension is in use, then that is probably what is at fault, and you should contact the extension’s author directly.

If not, then most likely the Inform 7 compiler is at fault. Please check that you have the currently distributed build of the system: if you have, please consider taking the time to fill out a bug report form and email it to the author.

Sorry for the inconvenience.

The 39269-word source text has successfully been translated into an
intermediate description which can be run through Inform 6 to complete
compilation. There were 542 rooms and 319 things.
Inform 7 has finished.

C:\Program Files\Inform 7\Compilers\inform-631
-wSDG +include_path=…\Source,.\ auto.inf output.ulx
Inform 6.31N for Win32 (29th March 2009)
auto.inf(33938): Error: No expression between brackets ‘(’ and ‘)’

         if (())

Compiled with 1 error and 1905 suppressed warnings (no output)

Compiler finished with code 1[/code]

It seems like I have too many loops in my code and I6 is protesting… :question:

I have been able to isolate the offending block (using remark brackets and process of elimination) and the block will code fine without an “if” loop but will reject if I use an “if” loop.

This is also a recurring error because I got rid of the original method of accomplishing what I wanted and used an alternate method and eventually got the same compiler results (but at first it coded fine (because there were less if loops)).

I’m thinking I can use a setting like MAX_STATIC_DATA or MAX_OBJECTS to fix this but I don’t know what it would be. Like MAX_LOOP_RAM or something :laughing:

Help. :nerd:

Are you using the “python style” indenting for your loops? If so, you can’t exceed 9 tab stops. If you are, you’ll need to switch to the “begin / end” style for the offending code block. (You can still use the indent style elsewhere – i.e. you can mix styles in a single work, but not withing a single block of code.) Also, if you are indeed relying on loops with more than 9 levels of indentation, I’d recommend against it; there are certainly ways of coding them without doing so.

If that’s not your issue, you’ll probably need to post the offending code block for a better answer.

ok, this fails:

fileCommand is an action applying to nothing. Understand "next" and "back" and "stop" as fileCommand. carry out fileCommand: if the player's command matches "stop": now current topic is none; now bookmark is 1; say "[line break]You close the reference files."; now the highest cabinet north section is closed; if the player's command matches "next": if the current topic is history: if bookmark is 1: now bookmark is 2; if bookmark is 2: say "test"; if bookmark is 3: say "test"; if the current topic is geography: say "test"; if the player's command matches "back": say "test";
:question:

Here is the user-friendly version which also fails:

[code]limbo is a room.

current topic is a kind of value. the current topics are history, geography and none.

bookmark is a number variable.

highest cabinet north section is an openable closed container.

fileCommand is an action applying to nothing. Understand “next” and “back” and “stop” as fileCommand.
carry out fileCommand:
if the player’s command matches “stop”:
now current topic is none;
now bookmark is 1;
say “[line break]You close the reference files.”;
now the highest cabinet north section is closed;
if the player’s command matches “next”:
if the current topic is history:
if bookmark is 1:
now bookmark is 2;
if bookmark is 2:
say “test”;
if bookmark is 3:
say “test”;
if the current topic is geography:
say “test”;
if the player’s command matches “back”:
say “test”;[/code]
:cry:

Well this blows my theory that it is some kind of “if loop buffer” limit. It is funny how the system accuses itself of being wrong. :laughing:

This also fails:

[code]limbo is a room.

current topic is a kind of value. the current topics are history, geography and none.

bookmark is a number variable.

highest cabinet north section is an openable closed container.

fileCommand is an action applying to nothing. Understand “next” and “back” and “stop” as fileCommand.
carry out fileCommand:
if the player’s command matches “stop”:
now current topic is none;
now bookmark is 1;
say “[line break]You close the reference files.”;
now the highest cabinet north section is closed;
if the player’s command matches “next”:
if the current topic is history:
say “test”;[/code]

Now its looking like its just a nested if that’s doing it. :neutral_face:

[code]limbo is a room.

current topic is a kind of value. the current topics are history, geography and none.

bookmark is a number variable.

highest cabinet north section is an openable closed container.

fileCommand is an action applying to nothing. Understand “next” and “back” and “stop” as fileCommand.
carry out fileCommand:
if the player’s command matches “stop”:
now current topic is none;
now bookmark is 1;
say “[line break]You close the reference files.”;
now the highest cabinet north section is closed;
if the player’s command matches “next”:
say “test”;[/code]

And this will work. So no nested if’s with Inform 7 :cry:

Well, you can definitely do nested "if"s in I7. I think the problem is more likely to be very specific, say something more like: “No nested if’s in action rulebooks when the top-level ‘if’ is a reference to the player’s command”–in other words, a bug rather than a limitation. (I’m not sure that’s actually the limitation, but it provides a starting point for determining exactly what is needed to produce the error.)

As a side note, you would do better to break these up into separate actions (i.e., “back” “next” and “stop” implemented as separate actions). Parsing by hand in this way is not really to be recommended.

–Erik

Well I originally had them as separate actions but made a catchall because of the bug.

This is not normal parsing as these are specific commands that only apply when a certain file drawer is open.

I’m trying to figure out a way now to get around this “no nested if within an action” limitation…

If only I could manually call an action it would solve everything. :cry:

Hahaha, I’ve been actually thinking of trying to replace the player’s command with a command to call another action but I’m too afraid to get into that… :laughing:

Yikes! The user-friendly version is a standalone! :astonished:

Oh dear goodness…

What could this be??

Well, you can do things like this:

Understand “next” as file-continuing when the drawer is open.
Understand “next” as queueing missions when the drawer is closed.

So, the same command typed at the keyboard will lead to two different actions, depending on the state of the drawer.

Is that the kind of thing you’re wanting to do? I can’t tell from your description whether you’re describing a circumstance that would force you to hand-parse using “the player’s command,” but it doesn’t seem like it.

–Erik

Looks like this is actually a bug in both I7 and your code: you’re testing whether a kind of value is something (like saying “if a number is 10…”), and I7 isn’t catching it.

You’re saying that

current topic is a kind of value.  the current topics are history, geography and none.

That just creates a kind of value, not a variable; you can’t test whether a kind of value is something. You have to create a variable that accepts that kind of values (just like you’ve done with bookmarks: “bookmark is a number variable”.) So, just change the above line into something like:

Subject is a kind of value. Subjects are history, geography and none. Current topic is a subject variable. Current topic is none.

Here is a direct quote from the Inform 7 manual:

[code](Thus far we have only given new properties to kinds, but in fact we can also give them to individual things, as here. It would be cumbersome to make a new kind called, say, “lamp” and then make the lantern the only lamp in the game, just as a way of attaching a number to it.) We could then set the brightness level to be 1, 2, 3 or 4 according to the strength of flame, and find some way of conveying this to the player. That would work, but is not very elegant. Brightness is not, in the end, a number, and it seems strange to have to pretend that it is. A much better solution is:

Brightness is a kind of value. The brightnesses are guttering, weak, radiant and blazing.

This makes “brightness” a kind of value on a par with (for instance) “number” or “text”, except that there are only four possible values, named as above.[/code]

What is freaking me out now is how stand-alone code fails on my machine but doesn’t fail on another person’s machine. :exclamation:

This code should fail on everyone’s machine, not just mine:

[code]limbo is a room.

current topic is a kind of value. the current topics are history, geography and none.

bookmark is a number variable.

highest cabinet north section is an openable closed container.

fileCommand is an action applying to nothing. Understand “next” and “back” and “stop” as fileCommand.
carry out fileCommand:
if the player’s command matches “stop”:
now current topic is none;
now bookmark is 1;
say “[line break]You close the reference files.”;
now the highest cabinet north section is closed;
if the player’s command matches “next”:
if highest cabinet north section is open:
say “test”;[/code]

Yeah, but that doesn’t mean what you probably think it means. It basically means that you can make new kinds of values, nothing more. (See also chapter 4.11.)

If you’re talking about my previous message where I said that the examples worked fine with me and which I deleted almost immediately: sorry about that. The last complete example did in fact not compile on my machine when I tested it just after posting. I didn’t think anyone had the time to read the post for the brief time it was up.

can u try the new one I posted? It has the double if in there…

[code]limbo is a room.

current topic is a kind of value. the current topics are history, geography and none.

bookmark is a number variable.

highest cabinet north section is an openable closed container.

fileCommand is an action applying to nothing. Understand “next” and “back” and “stop” as fileCommand.
carry out fileCommand:
if the player’s command matches “stop”:
now current topic is none;
now bookmark is 1;
say “[line break]You close the reference files.”;
now the highest cabinet north section is closed;
if the player’s command matches “next”:
if highest cabinet north section is open:
say “test”;[/code]

Omgosh… I think it IS that value thing… One sec while I test this a bit…

But there’s no reason to try this one. The root problem hasn’t been corrected, so if the code does work, it’s a fluke.

Juhana is correct that the problem is that you are using kinds of value incorrectly. You need to do something like this:

Information-topic is a kind of a value. The information-topics are history, geography, and none. Current topic is an information-topic that varies. Current topic is none.

–Erik

Yup! It works now!

WOW. Great catch Erik! :smiley:

Well it just goes to show you that the Inform manual isn’t perfect but I must say its much better thatn the TADS manual. :wink:

I think the TADS manual is good and took ALOT of effort to compile but unfortunately I just found it too hard to work with… :cry:

Thanks for your help everyone! :mrgreen:

Well, it was actually Juhana’s catch, not mine. :slight_smile:

The Inform manual actually seems to state this correctly and forthrightly to me, but maybe there’s something in the larger context that I’m missing.

–Erik

Hahah yes, Juhana!

Well I wasn’t able to find reference to the fact that kinds of values are not state checkable themselves but that only variables of value kinds are!

I think this might just be one “weak” area of the documentation that might need further clarification.

Maybe because the the entire concept is new to me (I’m a BASIC hack programmer from the '80’s) I am easily confused… :blush: