Next: , Up: Invoking ick   [Index]


2.1 Language-affecting Options

The following command-line options to ick affect what dialect of the INTERCAL language is compiled by the compiler; you may need to set one or more of these options if your input is not the default C-INTERCAL but instead some other language like INTERCAL-72 or CLC-INTERCAL, or just because you like certainty or like being different with respect to your output. Note that there is no command-line option corresponding to TriINTERCAL (or the base 4-7 versions); instead, the numeric base to use is determined by looking at the filename extension (‘.i’ for base 2, the default, or ‘.3i’ to ‘.7i’ for the base 3-7 versions.)

-b

If this option is not given, there is a small chance that a random bug appears in the compiler, which causes the programs it creates to manifest a bug that causes error E774 (see E774). Giving the option means that this bug will not happen. (You may wonder why this bug was preserved; it is in fact a bug that was carefully preserved since the days of INTERCAL-72, in this case, but the option to turn it off is available as a workaround. (There are no plans to fix this or any of the other carefully preserved bugs any time soon, because that would kind of defeat the point of having preserved them.) Interestingly, the INTERCAL-72 compiler documentation mentions a similar command-line option that is a workaround for the same bug.)

-m

This option needs to be given to allow any multithreading or backtracking commands or identifiers to be used. (Unlike with other language features, this is not autodetected because it’s legal to have a program with multiple COME FROM (see COME FROM) commands aiming at the same line even when it isn’t multithreaded, in which case the commands cause error E555 (see E555) when that line is encountered (with the usual caveats about both commands having to be active at the time).) Attempts to use non-COME FROM multithreading or backtracking commands without this option produce error E405 (see E405).

-e

This option makes it possible to link non-INTERCAL programs with INTERCAL programs; instead of giving INTERCAL programs only on the command line, give one INTERCAL program, followed by any number of programs in other languages that have been written to be able to link to INTERCAL programs. It also allows expansion libraries to be specified on the command line, after the INTERCAL program (expansion libraries are given with no extension). For more information, see External Calls. Also, both the -a and -e options must be set to use CREATEd operators (regardless of whether external calls are used or not).

-E

This option causes the system library to never be linked; this option is only useful if your program references a line number in the range 1000 to 1999, contains no line numbers in that range, and yet still doesn’t want the system library to be linked in; therefore, it is mostly useful with -e when adding in a custom replacement system library written in a non-INTERCAL language, especially the expansion library syslibc (a system library replacement written in C).

-t

This option tells the compiler to treat the source code as INTERCAL-72; as a result, any language constructs that are used but weren’t available in 1972 will trigger error E111 (see E111).

-a

This option allows the CREATE statement (see CREATE) to be used. Note that enabling it carries a run-time penalty, as it means that operand overloading code has to be generated for every variable in the program. (This option is not necessarily needed for the external call version of CREATE to work, but the external call version has fewer features without it.) Note that -e (see -e) also needs to be set to be able to CREATE operators.

-v

It is possible to write INTERCAL code sufficiently tortuous that it ends up assigning to a constant. Generally speaking, this isn’t what you wanted to do, so the compiler will kindly cause an error (E277; see E277) that stops the insanity at that point, but at the cost of a significant amount of performance you can give this option to tell the compiler to simply change the constant and keep on going anyway. (Note that unlike CLC-INTERCAL, this only changes uses of the constant preceded by # in your program, not things like line numbers; you want Forte for that.) This option also allows you to write arbitary expressions on the left of an assignment statement if you wish.

-C

When this option is given, the generated programs will write the number 4 as ‘IIII’ rather than ‘IV’, in case you’re writing a clock program.

-P

This tells the compiler to treat the input as PIC-INTERCAL (see PIC-INTERCAL) rather than ordinary C-INTERCAL input, and generate PIC output code accordingly. There are a lot of options that are incompatible with this, as well as many language features, due to the limited memory available on a PIC. If you get error E256 (see E256), you have this option given when it shouldn’t be; likewise, if you get error E652 (see E652), you should be using this option but aren’t. (A few simple programs are C-INTERCAL/PIC-INTERCAL polyglots, but such programs are incapable of doing input or output, meaning that they aren’t particularly useful.)

-X

The C-INTERCAL and CLC-INTERCAL compilers use different notation for various things, sometimes to the extent where the same notation is legal in both cases but has a different meaning. As this is the C-INTERCAL compiler, it rather guessably uses its own notation by default; however, the CLC-INTERCAL notation can be used as the default instead using this option. (In most situations where there isn’t an ambiguity about what something means, you can use the ‘wrong’ syntax freely.) The option causes ambiguous characters like ? to be interpreted with Princeton rather than Atari meanings.

-x

This option causes some constructs with different meanings in C-INTERCAL and CLC-INTERCAL to use the CLC-INTERCAL meaning rather than the C-INTERCAL meaning. At present, it affects the abstention of a GIVE UP (see GIVE UP) command by line number, which is possible as long as this switch isn’t given; reading through the INTERCAL-72 manual, there are a lot of things that imply that this probably wasn’t intended to be possible, but as far as I can tell that manual doesn’t actually say anywhere that this particular case is disallowed, even though it rules out all other similar cases. It also causes I/O on array variables to be done in CLC-INTERCAL’s extended Baudot syntax, rather than using the Turing Tape method.


Next: , Up: Invoking ick   [Index]