Question: Is it possible to insert mode declarations in Ciao-Prolog code?

Definitely! Look up part five of the manual:

* *** PART V - Annotated Prolog library (assertions):: * The Ciao assertion package:: * Types and properties related to assertions:: * Declaring regular types:: * Properties which are native to analyzers:: * Meta-properties:: * ISO-Prolog modes:: * Classical Prolog modes:: * Run-time checking of assertions::

One of the nicest characteristics of Ciao is that it allows declaring types, modes, and many other properties of programs (even user-defined properties) using a very powerful assertion language. To use this language you need to load the 'assertions' package and, if you want to use types, the 'regtypes' package (some examples are included in the manual). We strongly believe that an assertion language like this should be part of any modern logic programming language.

If the answer is yes, I could check how it influences speed.

Unfortunately, the low-level compiler in the distribution does not do much with many of these assertions. It does use them for example in higher-order programming, in the database interface, for generating glue code in the C interface, etc., but not for optimization. On the other hand, 'lpdoc' (the autodocumenter, which is distributed with Ciao) understands the full assertion language and uses any assertions present in programs to automatically generate reference manuals. Typically, it pays off to put assertions for the exported predicates of a module even if were only for documentation purposes.

By the way, I do not want to keep with Mercury because it generates ridiculously large code (ten times larger than Ciao Prolog, or GNU-Prolog). Finally, I am giving up Visual Prolog because it requires type declaration.

Visual Prolog stems from Turbo Prolog, and belongs to a school of thought that developed early in logic programming where the philosophy was to *require* mode and type declarations (and impose restrictions in the language and pay in larger code size and compilation times) in exchange for more speed (Mercury also includes enhancements related to purity and declarativeness).

In Ciao (and in its predecessor, &-Prolog) we have always proposed an alternative model:

- The language should not be restricted.

- Declarations of program properties (modes, types, and others) should be voluntary, not compulsory. This allows programming 'in the large' (with modules with documented interfaces) and at the same programming in the small (small applications, scripts, prototyping, etc.).

- Speed (and error checking!) should be achieved by performing *inference* of modes, types (and many other properties).

- The user should be able to choose between traditional bytecode compilation (which has the advantage of reasonable speed and reasonable code size) or different degrees of optimized compilation (exchanging code size and compilation time --possibly including the time to infer types, modes and other properties-- for speed).

Our confidence from the very start in this model stemmed from our experience developing practical algorithms and tools for inference of modes, types, and many other properties since the late 80's, and experimental results (early work of Tick, VanRoy, etc.) that proved that with this information things could be sped up to essentially C speed.

Interestingly, the original design of Mercury implied compulsory declarations, and argued strongly for them. Over time the Mercury designers have progressively allowed fewer declarations, turning more towards inference (and, we argue, towards the Ciao model :-)), although the Mercury language itself still keeps the restrictions.

Is it possible to add an option to Ciao Prolog to generate mode and type inference? Of course, it is possible. I think I should rephrase the question. Do you have plans to add mode and type inference to Ciao-Prolog?

Actually, Ciao does have mode and type inference! This is done by the Ciao preprocessor 'ciaopp' (which contains our 'abstract interpreter', PLAI, which --please allow us some bragging-- was arguably the first tool ever to do this task in a truly practical way). In fact, ciaopp can also do many other things --I have included ciaopp's README at the end of the message for those who are curious, and also a pointer a paper which explains in more detail the functionality of ciaopp and has references.

Ciaopp has been available for quite a while for research purposes (and is used by us and by many other people). Unfortunately, up to now we have concentrated on getting a high-quality, well documented system, with a large set of libraries (i.e., Ciao itself, and the lpdoc autodocumenter). We have not had the time to make ciaopp as stable as the rest of Ciao (and we are always experimenting with it, because it is our main research platform). This is why we have not put it yet for download at the Ciao distribution site (we provide it on demand, if/when we have a more or less stable version through our Beta site). However, we should have an official distribution soon. The current version works with ciao-1.6 and we are finishing the version that runs with 1.8 (which has just been released).

Now, for the other side of things: once types, modes, etc. are available (whether inferred or declared) is to generate optimized code, i.e., to get the speedups. You have experience in this:

With this off-hand scheme, I was able to compile only very simple programs. However, they proved to be as fast as equivalent programs in Mercury.

Very interesting! As Manuel Carro mentioned in his message, we have also been working in this direction for a while and have prototypes which confirm your experiments (and that of the others mentioned above and our early intuition when we designed Ciao): if you use the inferred information you can achieve Mercury speed. The problem in getting a truly production-quality system is again that we have limited resources, and it takes a while to have a system that is as stable as the emulator in the Ciao distribution (which, by the way, stems from a circa '87 SICStus emulator).

Would you accept volunteers? I am sending copies of this letter to Dr. Cedric and Dr. Marcus. They know well the kind of programs I write, and they may make suggestions. I am also sure that they would be happy to work as volunteers in your Prolog to C compiler, if you accept volunteers, of course.

Yes, it seems like we have grounds for collaboration. Also, there are several people in the world working on these topics (not necessarily for Ciao, but on the general problem). Bart Demoen for example is also working on this very subject. We look forward to exchanging more technical details on how the different pieces that we have fit right now.

Cheers,

Manuel Hermenegildo

PS: We would be very interested in getting your program so that we can analyze where the speed differential is coming from. Is it possible to get a copy of it?

*** The ciaopp readme:

README

---

`ciaopp' is the precompiler of the Ciao Prolog development environment. `ciaopp' can perform a number of program debugging, analysis and source-to-source transformation tasks on (Ciao) Prolog programs. These tasks include:

• Inference of properties of the predicates and literals of the progam, including types, modes and other variable instantiation properties, non-failure, determinacy, bounds on computational cost, bounds on sizes of terms in the program, etc.

• Certain kinds of static debugging, finding errors before running the program. This includes checking the ways in which programs call the system library predicates and also checking the assertions present in the program or in other modules used by the program. Such assertions essentially represent partial specifications of the program.

• Several kinds of source to source program transformations such as program specialization, program parallelization (including granularity control), inclusion of run-time tests for assertions which cannot be checked completely at compile-time, etc.

The information generated by analysis, the assertions in the system libraries, and the assertions optionally included in user programs as specifications are all written in the same assertion language, which is in turn also used by the Ciao system documentation generator, `lpdoc'.

`ciaopp' is distributed under the GNU general public license.

*** A basic reference on ciaopp (has also pointers to related papers, many available from http://www.clip.dia.fi.upm.es/):

@inproceedings{ciaopp-iclp99-tutorial, author = {M.~Hermenegildo and F.~Bueno and G.~Puebla and P.~Lopez-Garcia}, title = {Program Analysis, Debugging and Optimization Using the Ciao System Preprocessor}, booktitle = {1999 International Conference on Logic Programming}, year = {1999}, month = {November}, pages = {52--66}, publisher = {MIT Press}, address = {Cambridge, MA} }