ECLiPSe loops and logtalk

[WitJakuczun]

Hi,
is it possible to use ECLiPSe loops in logtalk objects? I tried the
following code:

Code: Select all

   :- object(test).
       :- publict(predicate/0).
       predicate :-
          ( count(I, 1, 10),
             foreach(I, Is),
           do true
          ),
          writeln(Is).
   :- end_object.

Unfortunatelly this code does not compile. I get the error: "syntax error: postfix/infix operator expected".
I would be grateful for explanation.

Best regards
Wit Jakuczun

[Paulo Moura]

Hi!

I'm looking at the ECLiPSe loop control constructs now. I will post later my findings. Meanwhile, you may use as an alternative the Logtalk library object "loop", which provides several imperative programming style loop predicates:

Code: Select all

:- object(test). 

	:- public(predicate/0). 

	predicate :- 
		loop::forto(I, 1, 10, YourGoalHere),
		...

:- end_object.

To use the "loop" library object type:

Code: Select all

{library(loopp), library(loop)}.

or, to take advantage of static binding:

Code: Select all

logtalk_load([library(loopp), library(loop)], [reload(skip)]).

Happy logtalking!

Paulo

[Paulo Moura]

Hi!

It seems that the ECLiPSe "do" operator is not available when the library(iso) is used. This library is loaded by the ECLiPSe config file, "eclipseiso.config", which is the default config file when using the provided Logtalk integration scripts. Thus, one solution is to not use operator notation. With the following definition:

Code: Select all

:- object(test). 

	:- public(predicate/0). 

	predicate :- 
		do((count(I, 1, 10), foreach(I, Is)), true), 
		writeln(Is). 

:- end_object.

there are no longer compilation or execution errors:

Code: Select all

[eclipse 1]: {ecl}.
<<< loading source file ecl... 
>>> compiling source file ecl...
compiling object test... compiled
>>> ecl source file compiled
ecl.pl     compiled optimized 1952 bytes in 0.00 seconds
<<< ecl source file loaded
(0 warnings)

Yes (0.01s cpu)
[eclipse 2]: test::predicate.
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Yes (0.00s cpu)

Another possible solution is to add an op/3 directive to your source file for the "do" operator:

Code: Select all

:- op(1100, xfy, do).

Note, however, that the Logtalk "loop" library object results in a portable solution (across all Logtalk compatible Prolog back-end compilers). The ECLiPSe loop control constructs, even if handy, are proprietary and, as such, not easily portable.

Happy logtalking!

Paulo

[WitJakuczun]

Note, however, that the Logtalk "loop" library object results in a portable solution (across all Logtalk compatible Prolog back-end compilers). The ECLiPSe loop control constructs, even if handy, are proprietary and, as such, not easily portable.

Thanks for suggestions. I will take a closer look on logtalk loops. Portability could be an issue if I decided to change prolog compiler.

Best regards
Wit Jakuczun

[WitJakuczun]

Hi!

I'm looking at the ECLiPSe loop control constructs now. I will post later my findings. Meanwhile, you may use as an alternative the Logtalk library object "loop", which provides several imperative programming style loop predicates

Paulo

If I can suggest anything. Take a closer look at ECLiPSe's fromto general loop. It is really useful. There are also other features that make life easier (especially debugging), like loop's labels (in logtalk that could be solved via parametric object).

Best regards
Wit Jakuczun

[Paulo Moura]

Hi!

While keeping the portability issues in mind, it's also important to stress that calls to the ECLiPSe loop constructs are expected to provide better performance than the use of the "loop" predicates. Logtalk recognizes the ECLiPSe do/2 predicate as a built-in meta-predicate. Thus, calls to the ECLiPSe do/2 predicate from within objects (or categories) are further optimized when the Logtalk compiler calls the ECLiPSe compiler to compile the generated intermediate Prolog files. Moreover, both the "loop" predicates and the do/2 built-in predicate imply a meta-call. This meta-call (as long as it's instantiated at compile time) is optimized in the case of the do/2 *built-in* meta-predicate. This optimization does not take place when using the "loop" predicates because they are user meta-predicates, not *built-in* meta-predicates.

Happy logtalking!

Paulo

P.S. An update to the Logtalk compiler is planned that will apply the meta-call optimization to both user and built-in meta-predicates.

[WitJakuczun]

Hi!

While keeping the portability issues in mind, it's also important to stress that calls to the ECLiPSe loop constructs are expected to provide better performance than the use of the "loop" predicates.

Good point! Thanks.

P.S. An update to the Logtalk compiler is planned that will apply the meta-call optimization to both user and built-in meta-predicates.

Great.

Best regards
Wit Jakuczun
[/quote]

[Paulo Moura]

Hi!

If I can suggest anything. Take a closer look at ECLiPSe's fromto general loop. It is really useful. There are also other features that make life easier (especially debugging), like loop's labels (in logtalk that could be solved via parametric object).

The next Logtalk version will contain an updated "loop" library object. From the preliminary release notes:

Added foreach/3, forto/5, and fordownto/5 meta-predicates to the library object "loop". Updated the definitions of the forto/3-4 and fordownto/3-4 meta-predicates to allow the use of arithmetic expressions as arguments for convenience and clarity.

Far from the all the goodies in ECLiPSe but with a bit more of functionality. You may check the updated version using the links:

http://svn.logtalk.org/viewvc.cgi/logta ... iew=markup
http://svn.logtalk.org/viewvc.cgi/logta ... iew=markup

All the best,

Paulo