Page 1 of 1

project goal

Posted: 13 Oct 2017 10:09
by mdosnov2016
I have the following structure:

Code: Select all

predicates ... ...    generate_top() :-   ...    generate_top() :- ...                 run() :- %            console::init(), %            taskWindow::create(),             generate_top, !.     end implement backend     goal    backend::run().
and I receive the following compile error:

e631 The predicate 'goal/0', which is declared as 'procedure', is actually 'nondeterm' backend.pack

how can I overcome this error?

Michael Dossis

Posted: 13 Oct 2017 15:21
by Thomas Linder Puls
You must remove "nondeterm" from the declaration of backend::run.

But that will probably move the problem into the clauses of run.

Posted: 13 Oct 2017 16:10
by mdosnov2016
Dear Thomas,

I 've done what you recommended but now I have the following error:

e631 The predicate 'goal/0', which is declared as 'procedure', is actually 'nondeterm' backend.pack

can you please help me a bit more.

Posted: 14 Oct 2017 14:41
by Thomas Linder Puls
I am afraid that it doesn't add up: if backend::run is declared to be procedure (i.e. without nondeterm or the like), then the goal you write will not receive that error.

Posted: 15 Oct 2017 16:24
by mdosnov2016
when I declare:

Code: Select all

 run : () procedure ().
and in clauses section:


Code: Select all

generate_top() :-   not(file5x::existfile("ITF_FACT.DBA")),   itf_not_found_message, !.    generate_top() :-   %openfile(stdout),   %writedevice(Oldoutput),   file5x::writedevice(fileSelector::screen),   file5x::write(" backend HLS CCC string started, please wait..."),   file5x::existfile("ITF_FACT.DBA"),   assertz(consecutive_106("false")),   assert_global_constraint_conditionally0,   check_for_program_name,   itf_found_message,   report_global_constraint,   file::consult("ITF_FACT.DBA", backend_dbase),   hdl_style(Hdlform),   extract_loops_from_all_modules(2), % don't process the ADA package   generate_hdl_recursive(Hdlform, "synergy", 1),   end_time_message,   %openfile(stdout),   file5x::writedevice(fileSelector::screen),   file5x::write(" backend HLS CCC string completed, feel free to check results!"), !   .           run() :-             generate_top.   end implement backend     goal  backend::run().

now I am getting the following error:

e631 The predicate 'backend::run/0', which is declared as 'procedure', is actually 'nondeterm' backend.pack

Posted: 15 Oct 2017 16:27
by mdosnov2016
when I also declare:

generate_top : () procedure.

then I get the error:

e631 The predicate 'backend::generate_top/0', which is declared as 'procedure', is actually 'determ' backend.pack

can you please give me an example of how to call a predicate (determ) inside a procedure
because I am confused and it doesn't seem to end the problem.

Michael Dossis

Posted: 15 Oct 2017 17:10
by Vitaly Markov
Edit a clause:

Code: Select all

run() :-     generate_top,!;     console::write("Error").

Posted: 15 Oct 2017 20:45
by mdosnov2016
I tried to include the write predicate as you recommended but I got thousands of errors that certain
libraries and includes are not found.

Do you have an easier procedure instead of write?

thank you,

Michael Dossis

Posted: 16 Oct 2017 15:34
by Thomas Linder Puls
I think it would be a good idea to leave your migrated project for a while and instead focus on getting to know the "new world" in a simpler context.

You can start with the Tutorials.

Posted: 19 Oct 2017 7:24
by mdosnov2016
Dear Thomas,
I think that it 'd be a very good idea also to have a continuation and backward compatibility
when you issue new versions of Prolog.
It is not realistic to ask experienced users of VP to throw away everything they knew about
the language and their projects and start again from scratch. This is just not logical.

I am prepared to learn the new feature of object oriented prolog but I don't have the
project time available to abandon my project and start from the begining.

I 've already, and with your help I manged to have a compiled and built 64-version of my project
which is what I wanted, but some of the prolog predicates don't behave the same as the
VP 5.x ones.

I will be relying on your valuable help to bring this project into a completion state.
Thank you,
Michael Dossis

Posted: 19 Oct 2017 9:00
by Thomas Linder Puls
Well the last Vip5 version was released around 20 years ago (I think). And the step from Vip5 to Vip6 was considered a step into a new language. Hence the need for a migration tool.

Besides this we strive to have a contemporary programming language and library and that from time to time requires a little backwards compatibility loss, adding such losses over 20 years it will of course be significant.

In Vip5 the procedure-check was not really that good. So you may experience that code that used to compile will no longer compile, because the compiler will for example say that a certain predicate is "determ" but should be "procedure". Backwards compatibility in such a case would be very strange, because the vip5 compiler was simply wrong about these things, and it would be very strange to maintain bogus behavior to preserve backwards compatibility.

Anyways, gaining knowledge about such differences may be easier in the simple contexts of tutorial programs rather than in the full complexity of a large migrated program. Hence the suggestion about going through some of the tutorials.

I do not in any way expect you to throw away your program. And also know that your questions are welcome.

Posted: 19 Oct 2017 13:38
by Paul Cerkez
If I might weight in a little here.

Building on what Thomas just stated, I was initially reluctant to move away from 5.x in a large project I had that was independently certified for safety use. I tried 'migrating' from 5.x to 6 when the change came about. It was a nightmare, all kinds of errors, some of the logic worked wrong. I was not enjoying the effort. Frustration level was high.

What i finally did was start a brand new 6.x project and completely 'recoded' the tool from scratch. I did not abandon my 5.x project. i used the knowledge I had of it, as well as some of the process flow and the embedded knowledge in the process to build a 'better' product.

I found I wrote less code because of new predicates then available, I didn't have to code in a 'work around' for some steps, and when all was over, the new code ran faster, code base (the EXE) was smaller, and the overall application was more stable in the latest version of Windows, and still maintains it certification.

When the time came to move it to 7.x, the migration was pretty simple.

the application now sits on the shelf collecting dust having been replaced by a US Government mandated "best of breed" application that still doesn't support what my application did. (they have been working it for 20 years to match my application's capability and functionality. they're close but still have a ways to go.)

Posted: 19 Oct 2017 14:40
by drspro2
the Determ vs Procedure error can always be solved like this:

basically you can make any function fitting into Procedure if you make sure that it always succeeds,
so , for example in the taskwindow, the event mostly needs to be procedure and must always succeed,

for example,


% add this so that the predicate always succeeds

event_predicate(_Src):- !.

,, All predicates of the previous Vip5 are present at the file5x and vip5x and conversion5x classes except,
for the concat,

old concat : concat("aa","bb",Resu), % Resu = "aabb"
new concat : Resu = string::concat("aa","bb"),

,, and then this principle:

example class function call : Resu = string::concat("aa","bb"), % double ::

or via object:

Obj = time::new(),
then use Obj:getTime(), % single :

the prolog language is so easy that it doesnt take much time to recode your previous code, it is the fastest
way, and will result in better versions, we could make a converter but it isnt worth the time invested for the return

you could for example post a small piece of old code, i could recode that code to the new code
as an example, it should be possible to recode the old version to new, and shouldnt be that much work

the errors Can occur a lot if syntax isnt right and for classes which dont exist,

Posted: 19 Oct 2017 14:52
by drspro2
in ol vip5

term_str(termStr) % (i,o) (o.,i)

is equivalent to:

Term = tryToTerm(domain, Str)

Str = toString(Term),

Posted: 19 Oct 2017 15:08
by Harrison Pratt
That's very good advice from Paul Cerkez.

I would like to suggest not trying to migrate an entire project at once. Instead, create a small "Test" project in 7.5 and migrate one small functional block (e.g. file input/output) of your 5.x code into a single class (e.g. FileIO with files "" and "" )in a 7.5 package (e.g. FileIO_PACKAGE) that you create from new in the Test project. In the Create Project Item dialog uncheck the Create Interface check box--you want to keep it simple and do not want to deal with object creation at this stage of your learning.

At first, it is easier to copy/paste your 5.x code into files created by 7.5 than trying to just move them into the package directory. That way you are sure that all the files are properly registered in the project. You don't have to copy all of the code from a 5.x file into the 7.5 file -- copy just one, or a few, predicates & clauses at a time until you are confident.

This approach will present you with a more limited number of compilation errors that you can sort out. You will find that 7.5 is more demanding with respect to clarity of predicates being procedure, determ, nondeterm, etc. This is a good thing, embrace it!

Once you get the FileIO class to compile and test satisfactorily, then you may enhance the FileIO_PACKAGE by addition another class, dialog or other project item.

Next you can create another small functional package in the same Test project and repeat the process.


If you are comfortable with regular expression search/replace you can use that to quickly convert a large number of predicate and fact declarations from 5.x style to 7.6 style. However, I think it best for you to work through your conversion in small steps at first.