🚀 go-pugleaf

In article <3631@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A.
O'Keefe) says:


>It would help if you indicated the language you are using.
>From the extremely confusing use of '=' for arithmetic, I
>infer this is Turbo/PDC ``Prolog''.

    Sorry about not mentioning that before.  You are right, this is(drum roll
please) PDC PROLOG! :-)

>The answer is simple:  say what you *really* mean.

>    build_board1(10).
>    build_board1(SquareNum) :-
>        SquareNum < 10,                 % <--- I added this condition.
>        NextSquare = SquareNum + 1,
>        build_board1(NextSquare),
>        assert(board(SquareNum," ")).

>Turbo/PDC Prolog may well be smart enough to notice that the argument
>to build_board1/1 is a strict input and that therefore cases matching
>the first clause _won't_ get far into the second.  SB Prolog certainly
>would.

    Running the above code does stop the code from looping forever.  However,
in PDC Prolog there are diagnostics you can run on your code.  It still
tells me the above routine is non-deterministic.  Here is the output:

DIAGNOSTICS FOR MODULE: C:\PROLOG\DETERM.PRO

Predicate Name   Type   Determ Size  Domains -- flowpattern
---------------- ------ ------ ----- ----------------------------
_PROLOG_Goal     local  YES       26  --
build_board1     local  NO       138 integer -- i
board            NOT USED            integer,string
---------------- ------ ------ ----- ----------------------------
Total size                       164

Size of symbol table=    393 bytes


>Many Prolog compilers operate a clause at a time (in some, such as ALS
>Prolog and QP3.0, assert _is_ "compile"), so won't spot this.  In such
>cases you must resort to an if->then;else (how does Turbo Prolog express
>if->then;else?) or use a cut:

>    build_board1(M) :-
>        (   M =:= 10 -> true
>        ;   M  <  10 ->
>            N is M+1,
>            assert(board(N, ' ')),
>            build_board1(N)
>        ).

    Pretty much the same way.  However, and this is a *big* however, you
can only enclose arithmetic expressions in parenthesis.  Trying a similar
program like above with the parenthesis would generate an error. :-(
    This means that many times you have to split the code into two or
more predicates.  I've asked PDC to change this on their next release; I'm
hoping they do.


                                                  [Tim]