Probably this theme should be discussed in another category (please, feel free to move this post for an appropriate category). Considering a team of Prolog programmers working on a big code, so some cares must be take into account. So, in this environment with some diversity comes some questions:
a) Is there any template or rules for coding in Prolog? I suppose that a standardization or good advises for this team of the programmers?
Some tips or strong recommendations for a Prolog style clean?
Prolog is declarative, so intuitively a good code must be self-documented,
good choices of predicate names, etc
b) Considering the code done, is there any tool to check the quality of these codes?
Any tool to measure a quality or quantitatively a code in Prolog?
c) About the modues, the structuring in modules should be the best practice for big projects?
Example
:- module(shapes, ).
:- use_module(library(lists)).
I had used it … is there any approach? Any advantage?
d) Finally, last question:
Is there any tool to convert code in another language to Prolog? For instance,
a code in C to Prolog
Surely someone already heard about these themes, once that the Prolog age and its success history
I am looking forward to hearing from you
Claudio
PS surely many from this forum have many knowledgment about these topics on Prolog in large scale and cares
Modules: Every file should be its own module, no question.
Except: there are some meta-programming techniques like code interpreters, goal expansion, operator definition, etc. Such things can greatly improve the power of your code, but you need to control that carefully. You can make stuff that nobody understands if you get carried away.
Code translation: There is no chance of converting C to Prolog and doing that effectively. You can however invoke C code from Prolog. You can write programs to translate data structures in C to terms in Prolog.
Algorithms: You didn’t mention this, but if you are working at scale you need to understand how Prolog does things efficiently. Because it doesn’t normally support modifying, you have to approach things different than you would in C. There are things like red/black trees that are useful to know, so you don’t do things like replace a list or term/array with a different one, incurring huge overhead each time.
Quantitatively you will want to use the Profiler any time the program starts to seem slow.
Your advises are very welcome for me. I got them. At moment, I am search for any tool or methodology to do a conversion from a procedural language to Prolog. As you write, some algorithms are completely different in their structures.
Why do you want that? Do you have a lot of procedural code as a starting point and you want to convert your project to Prolog? I doubt that is going to work. Most of the research is in how logical languages are translated to imperative languages rather than the other way around. Of course it is theoretically possible, but the result is quite likely long and hard to read (and thus maintain) Prolog.
I’ve seen one big project going this way. They started introducing Prolog by creating a hybrid environment and over the years the Java part got smaller and smaller and the Prolog part grew.
One of the few exceptions where translation could be useful is rather simple imperative code doing a lot of numerical work, i.e., just a simple straight workflow with lots of arithmetic. Such code is fairly easy to recode in Prolog, but the process is tedious and error prone.
Yes in this direction, but there are strong reasons to use Prolog and convert just a small part from another procedural language. For confidential reasons … I can not explain here.
‘’… , i.e., just a simple straight workflow with lots of arithmetic. Such code is fairly easy to recode in Prolog, but the process is tedious and error prone.‘’
Yes, we are doing it, and these errors we are trying to identify in advance … with a good customization to Prolog.
Is there any tool to help in this task? Mainly, a checker to bare analysis giving some feedback such: "how trust a code in Prolog is being produced? "
Anyway, all the comments here were must welcome, I already a idea about this, but I would want heard other opinions. Now, I will be searching the material and links mentioned.
Unit tests. If you can test the input/output of your other code, you can translate those tests relatively easily to Prolog, and then your translated tests will verify the code was converted correctly.
Not readily available. The ffi add-on contains a C parser, but that is really low level (it parses the output of the preprocessor to extract type information). In the (distant) past I have written parsers for real C code in Prolog to translate the code, in this case to different C code.
Its not that interesting if you have a couple of pages of C, but if you have hundreds of them it may be worth the trouble. It could also translate unit tests, etc.
To be honest, I wouldn’t go down the route of unit tests. I would rather formulate an operational semantics for the source language then implement those rules directly in Prolog. Here’s an example for a toy imperative language (obviously to go from ‘toy’ to ‘proper’ is the challenge but it has been done for decent sized languages like SML for example):
Note my prolog implementation will lex ‘-------’ and ‘--------------’ or sequence of multiple '-'s as the same atom so my Prolog code is essentially ‘graphical’.
I am noting this not because it is an exact fit for your needs, but because there is often useful ideas and existing work in the packages that might be of benefit to a project.
Formulate an operational semantics for C and implement in Prolog? I would not dream of attempting such. SML has been done, but SML was designed from the start to be a formally precise language, and even that is a huge task.
I will be checking this question about an operational semantic of Javascript … maybe a same reasoning of a translation oriented by semantic instead of a syntax conversion.
Many ideas already collected … since the interesting tools from Logtalk (by Paulo Moura), unit tests, difficulties, translation oriented to a semantic, finally about an operational semantic … well I will be considering all these points for these next days.