Compile Time

The time at which a language processor such as cc or javac translates the source code. Contrast with RunTime, LinkTime?, LoadTime?, ExpandTime?, ReadTime?, BuildTime?, TestTime?.

Know what your language and tools do or can be asked to do at compile time or other times.

Is the distinction between CompileTime, LinkTime?, and BuildTime? really useful when they all happen in a single button click in most decent development environments ?

The CompileTime versus RunTime distinction is part of the definition of macros -- not just C macros, which some avoid altogether in C++, but in e.g. semantic LispMacros -- arbitrary Lisp code run at CompileTime (or better, ReadTime?) rather than at RunTime, and in Html templates. And since some tests are extremely time consuming, it's hard to imagine TestTime? ever disappearing altogether.

And from the beginning of computer history, LinkTime? has not always been a separate phase, but it is nonetheless always an important phase whenever shared libraries are supported. Furthermore there is sometimes a LoadTime? phase distinct from LinkTime?.

No matter how fast these different phases are, to a systems implementor they are nonetheless distinct phases, which don't go away simply because the user doesn't notice them! -- DougMerritt

But they might go away if the systems implementor redesigns the system in a non-traditional way. I've expanded upon the below a bit in explanation.

The distinction between CompileTime and RunTime becomes blurred with JustInTime compilers/interpreters and TransMeta's "CodeMorphing?". More generally, it becomes blurred in any language that comes with a full compiler as a standard part of its runtime.

The distinction between CompileTime and LinkTime? becomes blurred with AspectOrientedProgramming that can potentially invade 'shared libraries' or modules.

The distinction between CompileTime and TestTime? can become blurred in languages that support MetaProgramming that also offer a mechanism for both CompileTime evaluation and for intentionally creating a CompileTime failure (e.g. through the TypeSystem, or some sort of language-supported assertions mechanism). Of course, this will only handle a certain subset of tests and code-proofs; it is likely that the extremely time-consuming tests, or those that may have large side-effects, are still made distinct.

The distinction between CompileTime and LoadTime? and RunTime can become blurred in languages and frameworks that allow for an EventDrivenProgramming process model. If the language and framework are designed to work with one another, merely having a static (on disk) and properly named compiled object could qualify, essentially, as a 'loaded program', complete with access to persistent state and other services, that will spin off a short procedure to handle incoming messages. In fact, intentionally blurring CompileTime, LoadTime?, and RunTime is listed (indirectly) among the desired NewOsFeatures: treating compiled objects and files and such equally as part of an 'naked' object framework that can receive messages, expose procedures, have value-components, etc. The trick is getting rid of the procedural service loop - the 'main' method - since once that is gone the framework can easily support millions of processes and objects and files, statically, stored on disk when not in immediate use, all on equal grounds. It is likely that a WikiIde would need to take this approach, and I know that RK's BlueAbyss was heading for it. It is very likely that this will be the process and application model of the future (undoubtedly combined with some sort of ImmediateModeGui + CSS when representing processes to the user).

Finally, even the distinction between BuildTime? and CompileTime can become blurred in languages that support control of automated linking and resource acquisition from within the language (thus avoiding the need for a makefile or third-party-language 'script' to control the build). Traditionally, BuildTime? is used for resource acquisition and explicit combination (e.g. the makefiles and scripts, multi-language issues, compiling CORBA templates into C++ objects, etc.) If we ever intend the ability to have a OneLanguageEnvironment? (where we can get everything done without leaving the language), compile-time resource acquisition and linking will need to be part of it in addition to obviating the need for third-party support for MetaProgramming (i.e. some fairly generic syntax extension must be possible - maybe even semantics extension via some form of AspectOrientedProgramming). Of course, if we have AspectOrientedProgramming, CompileTime and LinkTime? need to be combined anyway - it wouldn't be a bad idea to go ahead and sweep in BuildTime? resource-acquisition at the SameTime (or JustInTime), so that the language can handle and metaprogram with arbitrary resources - not just other libraries. The language would be far more flexible for it, and programmers wouldn't need to work with multiple languages just to get things done.

If one blurs BuildTime?, CompileTime, LinkTime?, LoadTime?, and RunTime into BCLLRTime, then the only distinctions left are CodeTime?, BCLLRTime, and TestTime?. For the end-user (the programmer) it may be beneficial for the framework to blur CodeTime? and BCLLRTime via some sort of automated compile (e.g. much like the Wiki, where the 'source' for the page can be edited, and the result can be seen immediately). And however much of TestTime? can be blurred with BCLLRTime without harm wouldn't be bad at all - but it will, even as far into the future as this eye can see, still be quite reasonable to have the 'object' expose a test procedure (or port accepting a test command) or to use one program to test another for the 'big' tests.

Things become a lot simpler for the language and framework users if BCLLRTime is blurred (even if it is blurred more by the framework than by the language) - not just for the programmers, but also any services the programmers choose to render as programs-creating-programs (objects creating objects). It's like the difference between a Wiki where one can immediately see what one edits, and one where a third party 'moderator' must come in, approve, and press a button to compile the edited page into HTML before using it. With this blurred time, one ends up with systems like QedWiki where simply writing up a page and drag-dropping components together can essentially create a new 'built', 'compiled', 'linked', 'loaded', and 'running' service or application that is there and available (and immediately testable) even after you close the browser and walk away. The idea for WikiIde embraces this possibility, since that's what Wikis are all about - providing a service immediately, upon pressing one button - like 'save'.

Regardless of the translation technology involved (traditional AheadOfTime? compilation, JIT compilation, compilation to ByteCode which is then executed on a VirtualMachine, interpreted text, etc.) there are still several useful thresholds to be crossed. Starting with the latest and working backwards:

Before/after the program starts running. In the days of C, this was easy to determine--a program was officially running when main() was called; neither the programmer nor the user had little control over what happened before that. In more modern languages, lots of things happen before main()--static constructors in CeePlusPlus and Java, class initializers in Java, automatic startup of multiple threads in concurrent programs, etc. Many of these happen in an indeterminate order as well. A more useful definition for "running", then, might be this: A program is "running" when it starts processing and reacting to user input (whether reading from a file or the console; examining environment variables, command-line arguments, or registry entries; or reacting to mouse or other controller events).
Before/after the program is loaded into memory. Again, this is not so clear-cut in modern environments. In the past, one had to mainly worry about overlays. Today, overlays are no longer used in most environments (thankfully), but one must worry about dynamically-loaded libraries and components (sometimes loaded under control of an already-runnign program; sometimes loaded automatically by the operating system) and the like--to say nothing about modern virtual-memory architectures which load in program pages on demand, and programming languages which are capable of compiling code (from text!) on the fly. But this threshold is still important because before it occurs; the program (and/or the tools that built the program) can make little or no assumptions about the environment it is run under; after loading starts the program (or the language/system runtime) can start to discover the environment and react accordingly.

It's an interesting question in the context of the GNU LGPL (http://www.gnu.org/licenses/lgpl.html), which is very C-oriented, because the LGPL refers extensively to the differences between compile time, link time, and run time in determining what is or is not a derived work. Is it possible that the LGPL makes no sense for languages where the distinction is not as clear as it is in C/C++? --StevenNewton

CommonLisp makes distinctions between read time, compile time, load time and run time but there are enough differences between CL and C/C++ that the LGPL is not recommended. The Lisp Lesser General Public Licence (http://www.cliki.net/LLGPL) is similiar in spirit to the LGPL but defines what is and isn't a derivative work of a CL library. -- ThomasAtkins?

It should be noted that many of the FreeSoftwareFoundations claims regarding what constitutes a derivative work, are untested. Quite a few attorneys think that dynamically linking to a library is insufficient to create a derived work. There is a long-standing debate on this topic.

CategoryTime