This document does not describe the Cedar language. The Cedar language is poorly documented. You may find an overview in OverviewDoc.Tioga. When desperate, you might consult the Mesa 11.0 manual (available in hardcopy). Both Cedar and Mesa 11 evolved from Mesa 5. The Mesa 5 manual is abundantly available as a blue-and-white. Almost all of the changes since then have been additions, rather than revisions.

This document cites a number of other Cedar documents, usually in the form [see CommandToolDoc]. This is a shorthand citation for

We're talking about the Cedar compiler. Cedar is a modular language: a program can be composed of several compilation units. The compiler compiles compilation units one-at-a-time. The only communication between compilations is via the file system. A compilation takes as input: 1) a Cedar source (in a file named "Foo.Mesa", for some "Foo") and 2) compiled modules (in files named "Bar.BCD", for various "Bar"s). A compilation produces as output: 1) an object file (named "Foo.BCD", when the source is "Foo.Mesa"), and 2) logs of errors, warnings, and other administrivia.

Use the command tool or the DF tool to BringOver the public part of Compiler.DF, from the release, into a directory that will be on your search path when you want to use it. [See CommandToolDoc for a complete description of the command tool, working directories, and search paths]. On public machines, you may expect that the current compiler has been fetched to the ///Commands/ subdirectory. But as an installation example, here's how you might install the Cedar6.0 version in a Commands subdirectory of your home directory:

Some people find it convenient to add a button to their CommandTools for invoking the compiler. See CreateButtonDoc.Tioga for how to do this.

Put entries like the following in your user profile in CommandTool.BootCommands, CommandTool.NewUser, CommandTool.PerLogin, and CommandTool.PerCommandTool as appropiate: ``CreateButton Compile Compile $FileNameSelection$'' or ``EnsureButton Compile Compile $ShortFileNameSelection$''. Really check out the user proile and create button documentation.

The compiler is invoked by issuing a command in a CommandTool [see CommandToolDoc]. The compiler registers three commands (in the directory it was BroughtOver into): "Compile" "RCompile", and "ComplexCompile". (There are .Load files for all of these so you needn't worry about issuing a run command to get the commands registered.) The commands differ in that the latter offers to parse a more complicated command-line syntax (that offers a few esoteric features unavailable from the simple command). RCompile is just like Compile except that it prefers to do its compilation on a remote machine (this uses the ``Compute Server'' — see SummonerDoc.tioga).

The compiler has not yet been adequately informed about directories. Note that the ComplexCompile form allows only directoryless file names. The simple form allows a directory part, but the compiler discards it for every use except naming the source file. Thus, if your CommandTool has working directory []<>A>, and you say

The compiler produces three kinds of "reporting" output. One is a very cursory progress report --- just enough to let you know something's happening, and how many errors and warnings there were. Another is a more detailed progress report, indicating things like time spent, size of input & output, and number of errors, for each compilation. Finally, there are the errors and warnings, if any, for each compilation.

The cursory progress report is printed in the CommandTool from which the compiler is invoked. The detailed progress report is put in a file named "Compiler.Log", in the working directory of the CommandTool from which the compiler is invoked. The errors and warnings may also be put in "Compiler.Log", or instead in "Foo.errlog" (where "Foo" is the root of the source file name). This is what the "g" option is about.

The compiler will accept source files prepared with Tioga. It looks only at the ASCII aspects of the source file. Thus, it does not see node structure, looks, formats, or styles. And although this slightly contradicts the preceeding, comment nodes (those whose "Comment" property is TRUE) are ignored.

Before reading a source file, the compiler checks to see if the file is currently being edited or saved. If it is being edited, the compiler will ask you to save the file, and wait for this to happen before it proceeds. If the compiler finds the file in the process of being saved, it will wait untill the save completes before reading it. The waiting is done by polling once a second, and if things happen too quickly, the compiler may get confused.

If the "g" option is on, the compiler will open a Tioga Viewer on "Compiler.Log" if any of the compiles from a command line fail. If the "g" option is on, and all the compiles from a command line succeed, and there is a Tioga Viewer on "Compiler.Log", the compiler will destroy it.

If the "g" option is off, the compiler consults the "Compiler.ViewSeparateLogs" entry in your user profile to find out what to do about errors and warnings. In either case, it will create a Tioga Viewer on the source file. If Compiler.ViewSeparateLogs is FALSE, it will add a button (named "ErrorLog") at the right end of the top row of the menu of the Tioga Viewer on the source file. When clicked, that button will open a Tioga Viewer on the error log from that source file. Unfortunately, sometimes there is so much stuff already in the first row of the menu that the "ErrorLog" button is posted past the right boundary of the Viewer (and hence is invisible and un-clickable). If Compiler.ViewSeparateLogs is TRUE, the compiler will instead immediately (upon errors or warnings) open a Tioga Viewer on the error log, rather than posting a button to do it. In either case, when it successfully compiles a module (no errors or warnings), it removes an "ErrorLog" button (if it can find one) from the source Viewer's menu, and destroys all viewers on the error log, and deletes the error log file.

The compiler looks at a few entries in your user profile. Some UserProfile entries are just providing an automatic insertion of switches in all your compiler commands; others are more peculiar (generally dealing with Viewers). [See the compiler section of UserProfileDoc].

Here is reasonable compiler section for a Cedar6.0 user profile:

This is not an exhaustive list of bugs.

If you compile and get (some kind of) fatal compiler error, it damages the compiler. It will not correctly compile statements with the CONDITION construct. Your only option is to rollback. If this happens to a compile done through the Compute Server, the remote machine must be rolledback. Obscure error messages will appear such as: