Drop the misleading Jit from CompilerForCAP

[mohamed-barakat]

No description provided.

[zickgraf]

I describe in the manual (right at the beginning) in which sense it still is a just-in-time compiler:

The compiler was started as a just-in-time compiler, that is, it needed some arguments to infer types
of variables. Although the compiler now supports precompilation and type signatures can be explicitly
given, it still is a just-in-time compiler in the following sense: Only methods for operations getting a
CAP category as the first argument can be found by the compiler, and an instance of a CAP category is
needed for method selection.

We also see this in Julia: Every time a new category is added, Julias JIT compiler triggers because compiling code independent of a concrete category is usually not enough.

Nevertheless, I would be open for dropping the Jit if we have a good replacement for the prefix CapJit.... I don't want to simply drop the Jit to clearly differentiate between operations of CAP and operations of CompilerForCAP. Note that some operations of CompilerForCAP actually live in CAP so they can be used without creating a hard dependency on CompilerForCAP. However, I do not provide the same stability guarantees for those as for other operations in CAP. I.e. operations with prefix CapJit can be dropped or changed without notice and without a backwards compatibility layer.

[mohamed-barakat]

Sorry, the title of the issue was also misleading :) What I had in mind is to replace CapJit by something like CapCompiler. The latter is meaningful in the above sense as well.

[zickgraf]

What I do not like about CapCompiler is that it makes names even longer. I have already thought about the following: It seems to be common to just add a "c" to a language to name its compiler, for example "rust" and "rustc". So we could talk about "capc" (which is even shorter than "capjit"). Examples:

• CapcAddTypeSignature
• CAPC_INCOMPLETE_LOGIC

The small "c" in the first case ensures that tab completion on CapC<TAB>ategory does not show everything in the compiler's namespace.

If course one might misread CapcAddTypeSignature as CapAddTypeSignature. But I don't think that's a big problem because CAP and CompilerForCAP don't really have names in common, so CapAddTypeSignature will probably never be installed.

[mohamed-barakat]

I agree :)