SICK(1p)
π SICK(1p) β Compiler for CLC-INTERCAL π
(User Contributed Perl Documentation, bestie β¨)
β¨ NAME β¨
sick β compiler for CLC-INTERCAL
π¦ SYNOPSIS π¦
sick [options] files...
π DESCRIPTION π
okay so sick is literally the main development environment for CLC-INTERCAL. If files are specified, they get loaded into the compiler: if they're not objects, they're considered program sources and compiled using the options in effect at the exact point where they appear on the command line. The object produced by the compilation is then kept in memory. periodt.
After all the things found on the command line have been processed in some way, the program passes all the objects to one or more backends to do things with. The default backend just saves the objects to file, but other options exist β for example, run the objects or produce program listings. Note that the action to be performed can be changed with command line options, and may be different for each object: the options in force at the time the object was loaded will be used to save or execute it. iykyk.
A future version of sick will also include an interactive mode in which these objects can be inspected, ran, single-stepped, debugged or simply left alone in memory while you do something more productive. manifesting that for us.
Each non-object file will be compiled using a compiler selected using command line options. If nothing is selected, the compiler depends on the file suffix; the compiler considers a suffix anything from the last spot in the name (including the spot), and the suffix usually ends with i, for example program1.i has suffix .i and program2.test.case.42.mublei has suffix .mumblei. cute.
The suffix selection rules are actually defined in the various sickrc files: the description below corresponds to the defaults set by the system.sickrc file included with the compiler, but your local installation may have changed that. so check ur local config, bestie.
πΈ CLC-INTERCAL program source
These files must have a suffix ending in i. If the suffix also contains clc as a substring, this makes sure the source will be considered a CLC-INTERCAL program; otherwise the interaction of the many suffix rules may end up selecting a different compiler. These files will be prefixed with the compiler object sick.io. slay.
π CLC-INTERCAL compiler source
These files must have suffix .iacc. These will be prefixed, by default, with the compiler object iacc.io and produce a compiler object (which can be executed as a program, but will do nothing β it's only useful as a preload before compiling from source). a little useless icon, but valid.
π C-INTERCAL program source
These files must have a suffix ending in i and containing a c or a t somewhere, but not contain clc as substring: for example, prog1.cli and prog2.ti are understood as a C-INTERCAL source, but prog3.clci and prog4.tclci are not (they are CLC-INTERCAL sources). These files will be prefixed with the compiler object ick.io. got it? got it.
π§ CLC-INTERCAL assembler source
These have suffix .iasm and will be prefixed with the compiler object asm.io.
β Traditional INTERCAL program source
These will have suffix .1972 or .1972i and will be prefixed with the compiler object 1972.io.
π₯ Compiler extensions
Any other letters in the suffix can be used to select compiler extensions. Note that when a suffix is shown exactly in the above list, for example .1972 or .iacc, there is no space for extra letters and there are no other extensions: if this is reqlly required, the language guessing mechanism can be bypassed as described later in this document. do not test this casually.
π Personality
By default, sick operates imitating itself. However it can imitate other compilers too by selecting a different personality. At present, imitating another compiler just means that different suffix rules apply. The main effect of the rules is that the default compiler changes from "sick" to "ick" or "1972" according to the personality; more information can be found in the online documentation or the CLC-INTERCAL-Docs package. personality hire but for compilers.
π Base
Numbers between 2 and 7 change the default base by loading compiler objects 2.io to 7.io. If more than one number is present, the largest one wins, so .32i is a CLC-INTERCAL program in base 3. Also note that the suffixes .1972 and .1972i do not take options, and the 7 and 2 in these suffixes do not select a base; all INTERCAL-72 programs operate in base 2 only. These options can be used with sick or ick and can be added to iasm by specifying them as additional preloads, e.g. -Ap5.
π Bitwise Divide
Letter d in the suffix adds the compiler object bitwise-divide.io, which changes the normal unary divide operation to use bitwise, rather than arithmetic, shifts. It can be used with sick but not with ick. It can also be used with iasm by specifying the compiler object as an additional preload.
π COME FROM gerund
Letter g in the suffix adds the compiler object come-from-gerund.io, which enables the COME FROM gerund statements; since ick does not parse such statements, this letter can only be used with sick, or with iasm by specifying it as an additional preload.
π©· Computed labels
Letter l (ell, not upper-case i) in the suffix adds the compiler object computed-labels.io, which adds grammar rules to parse computed statement labels; this can be used only with sick; ick would not be able to use this, and iasm can just put computed labels in the object where it wants them.
β¨ NEXT
Letter n in the suffix adds the compiler object next.io, which enables the NEXT statement in sick; since ick enables this by default, and iasm programs can just put the NEXT instruction in the object, this letter can only be used with sick.
π INTERcal NETworking
Letter r in the suffix adds the compiler object internet.io, which adds syntax for the STEAL, SMUGGLE and CASE statements; it can be used with ick or sick. It requires the INET extension to be installed. An iasm program may be able to take advantage of this by specifying it as an additional preload.
π System call
Letter s in the suffix adds the compiler object syscall.io, which hides a "PLEASE NEXT FROM (666)" in a dark corner of your operating system. Works with any compiler, even INTERCAL-72, but for iasm and 1972 it needs to be specified as an additional preload.
π§΅ Threaded program
Letter t in the suffix selects threaded mode by loading compiler object thick.io. This also changes the default compiler to ick if the suffix is .i: to use sick one would use something like .tclci. It also works with iasm and 1972 if specified as an additional preload.
ποΈ Wimp mode
Letter w in the suffix adds the compiler object wimp.io, which causes the program to start in wimp mode when it is executed. An equivalent result can be obtained by passing the --wimp option to the executable program. To use this option with iasm or 1972 specify it as an additional preload.
The actual list of suffixes recognised is specified by the file system.sickrc and can be modified by a system-wide file in /etc/sick (any file name in that directory as long as it does not start with a spot) or by a per-user .sickrc file in a user's home directory. See the "Misc options" below for a discussion on how and where sick finds these files, and the online documentation for description of the file format. tl;dr: check ur sickrc, bestie.
If a preload file is specified on the command line, the defaults derived from the suffix are not used. It is also possible to use default preloads from a different file suffix by explicitly saying --suffix=.S β in this case, the compiler acts as if the file had name name.S; it is also possible to use the --add-preloads option to always request the suffix-based guess, and in addition to that also load any preload file specified. flexible fr fr.
In addition, compiler objects are always recognised, with whatever suffix. These bypass the first compiler pass and jump directly to the runtime (just-too-late) compiler. However, if the optimiser has been selected when these objects were compiled, and there are no postprocessor statements, the just-too-late compiler will be automatically replaced by a more traditional "compile-time" compiler. If this is confusing, wait until you see the rest. and it gets weirder.
If a file is specified without suffix, and there is a compiler object in the include path with the same name and suffix .io, the suffix is automatically added, whether you wanted it or not. the audacity.
As soon as each program is written into sick, a pre-compiler will produce an internal compiler object. iconic behaviour.
It is possible to ask the compiler to produce a program listing; this may make the compiler run slower, for example because it'll have to remember a lot more information, depending on the type of listing selected. worth it for the aesthetic.
If sick enters interactive mode, these objects will be available in memory for single-stepping, running, or just ignoring completely and getting on with the real work (note that the interactive mode has been talked about repeatedly, but so far, not implemented). not implemented, bestie. don't @ me.
If sick loads all the required programs and objects successfully, but does not enter interactive mode, it will pass all the objects to the appropriate backends and then terminates. In the absence of a --backend option this means the single backend "Object", which reads the object back to disk using the file name specified by --output, or if that wasn't specified, using the original file name but replacing its suffix with .io; this behaviour can be modified using the options described below. so many options, so little time.
The compiler accepts more several options, some of which are documented here. Options and files can be mixed in any order, each file is loaded and compiled using whatever options precedes it on the command line. For example:
sick --verbose --optimise prog1.i --quiet prog2.i --batch
will tell you everything about compiling prog1.i but not about prog2.i. Both programs will be optimised. On the other hand:
sick --optimise prog1.i --nooptimise prog2.i --batch
will optimise prog1.i but not prog2.i.
okay so quick lil PSA bestie β every single option can be "undone" (and sometimes it's even clear how π), with two iconic exceptions:
--includeonly applies to all objects loaded after it--rcfileapplies to all objects, even the ones loaded before it (just to be different π )
fr fr, --rcfile works so differently from every other option that we genuinely aren't sure what happens if it shows up after any non-object file in the command line. So for simplicity: always specify it first. no cap.
β¨ User Interface Options β¨
So here's the tea π΅: at present, sick does not use any user interfaces and always runs in batch mode. But the UI selection options exist anyway, just in case one day we add support for them π«Ά. Which interfaces are available depends on which optional interface modules are installed, and the operating environment decides which ones can actually be used.
-X,--graphicβ Enters the X-based graphical user interface. Needs the optional UI-X package and its dependencies, and it'll only work if you're running in a suitable environment, for example X windows πΌοΈ.-c,--cursesβ Enters the full screen, curses-based interface. Needs the optional UI-Curses package and its dependencies, and it'll only work if you're running on a suitable terminal. These days that means anything except a line printer π.--lineβ Enters the line-mode user interface. Needs the optional UI-Line package and its dependencies, and it'll only work if you're running on a terminal which supports it. These days that means almost anything β¨.--batchβ Avoids entering interactive mode. This is the default if the standard input and output are not connected to a terminal and the X-based interface can't be started. It's also the default until we actually implement interactive mode π.-itype,--interface=typeβ Selects the user interface type. Currently, only X, Curses, Line and None are defined, but more can be installed as compiler plug-ins. If the interface selected is None, sick will work in batch mode. Also, an empty string will reinstate the default behaviour.
β¨ Source Character Set Options β¨
-a,--asciiβ Assumes that program source is in ASCII.-b,--baudotβ Assumes that program source is in Baudot.-e,--ebcdicβ Assumes that program source is in EBCDIC.-h,--hollerithβ Assumes that program source is in Hollerith.-g,--guessβ Does not make assumptions about the source character set. If the character set can't be guessed, it will produce an error π¬. This is the default.--charset=nameβ Assumes that program source is in the given character set. Valid values are currently ASCII, Baudot, EBCDIC, Hollerith, but others could be installed as compiler plug-ins; an emptynameis equivalent to specifying option--guess.
β¨ Code Generation Options β¨
-O,--optimiseβ Invokes the optimiser π₯. This is an upper case letter O, not a zero. This will cause the extra objectoptimise.ioto be prefixed after the last compiler and before the real program. The program is then executed: when the optimiser takes control, it will force compilation of the rest of the program (thereby executing the compiler at compile-time, instead of runtime as it normally does), and the resulting object is checkpointed, so the next time it will automatically skip the initialisation and compilation stages. In addition, the"optimise"register is set, instructing the compiler to invoke the optimiser when it runs.
If you specify both-Oand-poptimise(see below), you are asking for trouble, so don't do that π.
--nooptimiseβ Disables automatic preloading and execution ofoptimise.io.-oname,--output=nameβ Selects a name for the output file. Some character sequences are recognised insidename:%pgets replaced by the source program's filename with the suffix removed%sgets replaced by the appropriate suffix for the selected backend, without the initial spot%ogives you the original file name specified on the command line, without suffix (this can differ from%pbecause%pcan be prefixed with a directory from the search path)- finally,
%%produces a single%
The default is %p.%s, which produces the object name described at the beginning of this document. A suffix is not automatically added if the output name doesn't contain %s; this might be useful in conjunction with the Perl backend to produce a file without a suffix, for example:
sick --output=%p --backend=Perl sourcefile.i
will compile sourcefile.i and produce perl script sourcefile β¨.
The special backend "help" produces a list of all known backend names, and does not change the current list.
If the output file is specified as an empty string, the code generation step will never be done.
-Ltypes,--listing=typesβ Asks the compiler to produce a program listing;typesis a comma-separated list, and each element directs the compiler to produce a different program listing. At present, only"html"is supported, which generates a syntax-highlighted version intended to be combined with a stylesheet π¨. Use-Lnoneto disable source listing from the next object, and-Lhelpto show a list of supported listing modules (this doesn't change what will run, it just produces a list on standard output). It's possible to specify a single argument to a listing module by appending"="and the argument to the name β for example, the"html"module can be asked to load a stylesheet with something like-Lhtml=clc-intercal.css.-nname,--name=nameβ Sets the program's name, if the code generator requires it (currently, no backends use a name, but some of the future ones will π). The default is%o. The same%-escapes as defined for the output file name are defined.--ddirectory,--directory=directoryβ Forces all outputs to be produced indirectory. This works by generating an output name as described above, then replacing the directory part.-lnames,--backend=namesβ Selects one or more compiler back ends; the short option is a lower case "L", not an upper case "I". The default is Object, which produces a compiler object (suffix.io). The distribution also includes a Perl backend, which produces an executable Perl program (suffix.pl). In addition, the pseudo backend Run will run the program instead of producing any object β in this case, the output file name is ignored. Note that the program will only run if the compiler is in batch mode. Other back ends can be provided as compiler plug ins. The distribution also contains a ListObject backend, which does not produce executables but object listings. A future version might offer the option to "uncompile" the output of the ListObject back end, but this is currently impossible because not all the internal state of the object is provided β only the part which is likely to be useful to a human reader π« . For example:
sick prog1.i -lObject,ListObject prog2.i -lRun,Object prog3.i
will compile prog1.i to prog1.io (default backend), then compile prog2.i to prog2.io and also produce a program listing in prog2.iasm, and finally compile prog3.i, run the object immediately but also save it to prog3.io.
--bug=numberβ Selects a different probability for the compiler bug π. The compiler bug is implemented by initialising the compiler's state with the required probability: when a statement is compiled (usually at runtime), a"BUG"instruction is emitted with the required probability. The default is1%.--ubug=numberβ Selects a probability for the unexplainable compiler bug. This is the compiler bug which occurs when the probability of an (explainable) compiler bug is zero. Only wimps would use this option π . The default is0.01%.-pname,--preload=nameβ Selects a compiler object to prefix to the program. If this option is specified, the compiler won't automatically prefix objects as suggested by the suffix. The program'oo, ick'included in a previous version of CLC-INTERCAL used option-pto select a parser. Since the main use of preloads is to select an alternative (runtime) compiler, it's felt that it's appropriate to keep the same letter for this option β¨.
The file name specified does not include the suffix .io, which is always added. The file must be a compiler object, not source code.
The special object optimise should always be loaded via -O. Using -poptimise will not necessarily put the object in the correct place, and will not instruct the precompiler to do whatever magic it needs to do to bootstrap the optimiser.
To completely disable preloading (this is only done when compiling the optimiser, which is used to compile itself) use an empty string.
--nopreloadβ Resets the default behaviour of selecting preloads based on suffixes.-A,--add-preloadsβ Asks to do the normal suffix-based guess of preloads, then add to that the ones specified with--preload. This can be used for example to add a single preload to a pre-defined list π«Ά.--suffix=suffixβ Specifies a suffix to use when selecting preloads. If this option isn't specified, the suffix is taken from the file name to be compiled.--imitate=whomβ Specifies that different suffix rules apply by "imitating" another compiler; this functionality is still experimental π. The valuewhomcan be one of"sick","ick"or"1972".--clc-intercalβ Alias for--imitate=sick.--c-intercalβ Alias for--imitate=ick.--intercal-72,--intercal-1972β Alias for--imitate=1972.-Ipath,--include=pathβ Adds a directory before the standard search path for compiler objects and source code. If a file is accessible from the current directory, it is never searched in any include path.
If this option is repeated, the given paths will be searched in the order given, followed by the standard paths.
β¨ Misc Options β¨
In the absence of orders to the contrary, sick starts by looking for configuration files π. First the system search path is scanned to find any files of the form *.sickrc; if two files with the same name are found in different directories, only the first one is considered. If this search reveals a file called system.sickrc, this will be executed first: any other files found will be executed next in an implementation-defined order.
Okay so after it's done rummaging through the system directories, sick goes and peeks at the directory /etc/sick: literally any file chilling in there whose first character is not a spot gets executed, and the order it happens in is implementation-defined, so don't come for me about the sequence bestie π«Ά
And then, as the grand finale, it goes looking for the file .sickrc in your home directory, and if it's there, that gets executed too. π
-rname,--rcfile=nameβ pulls configuration from the file name before doing anything else. You can repeat this option, and if you do, those files get executed in the exact order you listed them. Heads up though: using this option also disables the search for configuration files described above, so the only files that get run are the ones you named on the command line. And just so we're clear β we say "get configuration" and "execute a file" like they're interchangeable, because a config file is literally just a special little program with weird syntax. It's giving "same thing, different font" β¨--nouserrcβ stops a user rcfile (.sickrc) from loading. This one's normally for installation time, so that older versions of CLC-INTERCAL can't interfere.--nosystemrcβ stops system rcfiles from loading (they usually live in/etc/sick) if any exist. Again, normally only used during installation so previous CLC-INTERCAL versions keep their hands off. Also: it limits the file search to the current "build" directory if there is one, which means any installed*.sickrcfiles get ignored. π-Rverb,---rcskip=verbβ tells the program to ignore the verb verb inside a sickrc file. Use case example: disabling the automatic loading of libraries when it looks like the program needs them, via--RGLUE. π--extension=nameβ asks the program to make sure it loads extension name. Usually unnecessary, because finding an extension's own sickrc file will load the extension anyway β but during installation sick doesn't know about this stuff yet, so the build system adds this option to be safe. π-v,--verboseβ tells you everything it's doing, on Standard Error.--stdverb=fileβ sends that verbose output to file instead.--traceβ enables tracing. If you're compiling from source, the compiler gets traced too. Wanna trace a program? Compile it to an object, then run it with--trace. π¦--stdtrace=fileβ enables tracing and picks an output file for all that trace info.--notraceβ disables tracing. But plot twist: preloadingtrace.iohas priority over this option, so it can still get you. π--grammar-profileβ enables grammar profiling, which produces a summary of how the compiler's grammar got used while compiling programs. Mostly useful for debugging new compilers or analysing how the parser is performing. The info goes to standard error, unless a previous--stdgrammar-profileoption (that's the next one, bestie) picked somewhere else for it.--stdgrammar-profile=fileβ enables grammar profiling and sends the output to file.--nostdgrammar-profileβ disables grammar profiling. This is the default, so if you did nothing, congrats, you already have it.--grammar-profile-max=numberβ if grammar profiling is on, only produce the first number lines of output. The output is sorted by decreasing count, so those are the number most "interesting" productions from a performance-analysis standpoint. β--grammar-profile-count=numberβ if grammar profiling is on, only produce output lines where the usage count is at least number.--grammar-profile-cost=numberβ if grammar profiling is on, only produce output lines where the estimated cost is at least number.-q,--quietβ stop talking to Standard Error. (Shhh. π€«)--timesβ prints a summary of the time taken for each major action. This setting is independent of--verboseand--quiet, so it does its own thing.--notimesβ does not print execution times. This is the default.--rclistβ prints the names of all rcfiles it found, and it prevents starting interactive mode. Names get prefixed with a "splat" symbol (*) if they would be executed according to other command-line options like--nouserrcand--nosystemrc, and no prefix if they wouldn't. So for example, to edit every file that would actually be executed, and to edit them in the order they'd be executed, run something like:
sh -c '"${EDITOR:-teco}" `sick --rclist | awk '"'"'$1 == "*" { print $2 }'"'"'`'
These weird sequences of sparks and rabbit ears are obviously there to cope with the quoting mechanisms of different shells. Iykyk. πβ¨
--interpreter=moduleβ uses an alternative CLC-INTERCAL Interpreter. The default is whichever Interpreter is considered the best at the time the program is distributed. (Main character energy, honestly. π)
π BUGS π
There are more options than ls(1). This is construed to be a feature. π«Ά
Some of the options are not documented here but are documented in the Docs package. Some are documented here but not there. Balance. π
πΈ SEE ALSO πΈ
The INTERCAL on-line documentation, or the contents of the Docs package. And if necessary, see a qualified psychiatrist. π
And that's the whole page, bestie β that's a wrap on SICK(1p). The footer tells us it's from perl v5.40.0, dated 2025-02-09, and it lives in section SICK(1p). Slay, go forth and let your config files execute you. π
ππ
π¦ where this page comes from
- debian trixie: clc-intercal 1:1.00-3
- ubuntu questing: clc-intercal 1:1.00-3
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms