Why are all versions of Logtalk numbered 2.x?
The number "2" in the Logtalk version number refers to the second generation of the Logtalk language. Development of Logtalk 2.0 started on January 1998, with the first alpha release for registered users on July and the first public beta on October. The first stable version of Logtalk 2.0 was released on February 9, 1999.
Why do I need a Prolog compiler to use Logtalk?
Currently, the Logtalk language is implemented as a Prolog extension instead of as a standalone compiler. Compilation of Logtalk source files is performed in two steps. First, the Logtalk compiler converts a source file to a Prolog file. Second, the chosen Prolog compiler is called by Logtalk to compile the intermediate Prolog file generated on the first step. The implementation of Logtalk as a Prolog extension allows users to use Logtalk together with features only available on specific Prolog compilers.
Is the Logtalk implementation based on Prolog modules?
No. Logtalk is (currently) implemented is plain Prolog code. Only a few Prolog compilers include a module system, with several compatibility problems between them. Moreover, the current ISO Prolog standard for modules is next to worthless and is ignored by most of the Prolog community. Nevertheless, the Logtalk compiler is able to compile simple modules (using a common subset of module directives) as objects for backward-compatibility with existing code (see the Prolog migration guide for details).
Can I use constraint-based packages with Logtalk?
Usually, yes. Some constraint-based packages may define operators which clash with the ones defined by Logtalk. In these cases, compatibility with Logtalk depends on the constraint-based packages providing an alternative for accessing the functionality provided by those operators. When the constraint solver is encapsulated using a Prolog module, a possible workaround is to use explicit module qualification, encapsulating the call using the
{}/1Logtalk control construct (thus bypassing the Logtalk compiler).
Can I use Logtalk objects and Prolog modules at the same time?
Yes. In order to call a module predicate from an object (or category) you will have to use explicit module qualification and enclose the call using the Logtalk control construct
{}/1(which allows you to bypass the Logtalk compiler when compiling a predicate call). Logtalk also allows modules to be compiled as objects. See the Prolog integration and migration guide for details.
The integration scripts/shortcuts are not working!
Check that the
LOGTALKHOMEandLOGTALKUSERenvironment variables are defined, that the Logtalk user folder is available on the location pointed byLOGTALKUSER(you can create this folder by running the shell scriptcplgtdirs), and that the Prolog compilers that you want to use are supported and available from the system path. If the problem persists, run the shell script that creates the integration script or shortcut manually and check for any error message or additional instructions. For some Prolog compilers such as XSB and Ciao, the first call of the integration script or shortcut must be made by an administrator user. If you are using Windows, make sure that any anti-virus or other security software that you might have installed is not silently blocking some of the installer tasks.
I get some errors while starting up Logtalk after upgrading to the latest version!
Changes in the Logtalk compiler between releases may render Prolog config files from older versions incompatible with new ones. You may need to update your local Logtalk user files by running e.g. the
cplgtdirsshell script. Check theUPGRADING.txtfile on the root of the Logtalk installation directory and the release notes for any incompatible changes to the config files.
Are my Logtalk applications portable across Prolog compilers?
Yes, as long you don't use built-in predicates or special features only available on some Prolog compilers. There is a compiler option (
portability) that you can set to instruct Logtalk to print a warning for each call in your code of non-ISO Prolog standard built-in predicates. In addition, it is advisable that you constrain, if possible, the use of platform or compiler dependent code to a small number of objects with clearly defined protocols.
Are my Logtalk applications portable across operating systems?
Yes. However, you may need to change the end-of-lines characters of your source files to match the ones on the target operating system and the expectations of your Prolog compiler. Some Prolog compilers silently fail to compile source files with the wrong end-of-lines characters.
Should I use prototypes or classes in my application?
Prototypes and classes provide different forms of code reuse. A prototype encapsulates code that can be used by itself and by its descendent prototypes. A class encapsulates code to be used by its descendent instances. Prototypes provide the best replacement to the use of modules as encapsulation units, avoiding the need to instantiate a class in order to access its code.
Can I use both classes and prototypes in the same application?
Yes. In addition, you may freely exchange messages between prototypes, classes, and instances.
Can I mix classes and prototypes in the same hierarchy?
No. However, you may define as many hierarchies of prototypes and classes as needed by your application.
Can I use a protocol or a category with both prototypes and classes?
Yes. A protocol may be implemented by both prototypes and classes in the same application. Likewise, a category may be imported by both prototypes and classes in the same application.
What support is provided in Logtalk for defining and using components?
Logtalk supports component-based programming (since its inception on January, 1998), by using categories (which are first-class entities like objects and protocols). Logtalk categories can be used with both classes and prototypes and are inspired on the Smalltalk-80 (documentation-only) concept of method categories, hence the name. For more information, please consult the documentation and the examples provided with the system.
What support is provided in Logtalk for reflective programming?
Logtalk supports meta-classes, behavioral reflection through the use of event-driven programming, and structural reflection through the use of a set of built-in predicates and built-in methods which allow us to query the system about existing entities, entity relations, and entity predicates.
Using compiler options on calls to the Logtalk compiling and loading predicates do not work!
Using compiler options on calls to the Logtalk
logtalk_compile/2andlogtalk_load/2built-in predicates only apply the file being compiled. If the first argument is a loader file, the compiler options will only be used in the compilation of the loader file itself, not in the compilation of the files loaded by the loader file. The solution is to edit the loader file and add the compiler options to the calls that compile/load the remaining files.
Gecko-based browsers (e.g. Firefox) show non-rendered HTML entities when browsing XML documenting files!
Using Gecko-based browsers (e.g. Firefox) show non-rendered HTML entities (e.g.
–) when browsing XML documenting files after running thelgt2xmlshell script in the directory containing the XML documenting files. This is a consequence of the lack of support for thedisable-output-escapingattribute in the browser XSLT processor. The workaround is to use other browser (e.g. Safari or Opera) or to use instead thelgt2htmlshell script in the directory containing the XML documenting files to convert them to (X)HTML files for browsing.
Why can't I use paths with the compiling and loading Logtalk predicates?
Currently, Logtalk requires that the arguments to the
logtalk_compile/1-2andlogtalk_load/1-2predicates be an entity name or a list of entity names. This is an unfortunate consequence of the lack of a portable operating system interface for Prolog compilers. There is simply no portable way of specifying file name paths which will work across all compatible Prolog compilers and operating systems. Nevertheless, file paths can be used indirectly through the definition of library paths and by using the notation<library>(<entity>)for compiling and loading source files. This notation improves portability when moving a Logtalk application to other Prolog compiler/operating-system as only the library paths would need to be updated in order for the compiling and loading calls to remain unchanged.
Is there a shortcut for compiling and loading source files?
Yes. With most back-end Prolog compilers, you can use
{File}as a shortcut forlogtalk_load(File).
Can I create standalone applications with Logtalk?
It depends on the Prolog compiler that you use to run Logtalk. Assuming that your Prolog compiler supports the creation of standalone executables, your application must include the config file for your compiler and the Logtalk compiler and runtime.
Is Logtalk implemented as a meta-interpreter?
No. Objects and their encapsulated predicates are compiled, not meta-interpreted. In particular, inheritance relations are pre-compiled. Moreover, no meta-interpreter is used even for objects compiled in debug mode.
What kind of code Logtalk generates when compiling objects? Dynamic code? Static code?
Static objects are compiled to static code. Static objects containing dynamic predicates are also compiled to static code, except, of course, for the dynamic predicates themselves. Dynamic objects are necessarily compiled to dynamic code. As in Prolog programming, for best performance, dynamic object predicates and dynamic objects should only be used when truly needed.
How about message-sending performance? Does Logtalk use static binding or dynamic binding?
Logtalk supports both static binding and dynamic binding. When static binding is not possible, Logtalk uses dynamic binding coupled with a caching mechanism that avoids repeated lookups of predicate declarations and predicate definitions. This is a solution common to other programming languages supporting dynamic binding. Message lookups are automatically cached the first time a message is sent. Cache entries are automatically removed when loading entities or using Logtalk dynamic features that invalidate the cached lookups. Whenever static binding is used, message sending performance is essentially the same as a predicate call in plain Prolog. Performance of dynamic binding when lookups are cached is close to the performance that would be achieved with static binding.
Which Prolog-dependent factors are most crucial for good Logtalk performance?
Logtalk compiles objects assuming first-argument indexing for static code. First-argument indexing of dynamic code, when available, helps improving performance due to the automatic caching of method lookups and the necessary use of book-keeping tables by the runtime engine (this is specially important when using event-driven programming). Dynamic objects and static objects containing dynamic predicates also benefit from first-argument indexing of dynamic predicates. In addition, message processing may imply two meta-calls (in order to verify if a message is valid and to translate between the message term and its internal representation). Therefore, good Prolog performance on meta-calls translates to improved message processing performance.
How does Logtalk performance compares with plain Prolog and with Prolog modules?
Plain Prolog, Prolog modules, and Logtalk objects provide different trade-offs between performance and features. In general, for a given predicate definition, the best performance will be attained using plain Prolog, second will be Prolog modules, and finally Logtalk objects. Whenever static binding is used, the performance of Logtalk is close to that of plain Prolog. You can find here some simple benchmark tests using some popular Prolog compilers.
Is the Logtalk use and distribution license GPL compatible?
Logtalk follows the Artistic License 2.0. The FSF describes this license as a GNU GPL compatible, non-copyleft, free software license.
Can Logtalk be used in commercial applications?
Yes. Please consult the Logtalk use and distribution license for details or contact the author.
Are there consulting, training and supporting services besides the ones described on this web site?
Please contact the author if you need consulting, training and supporting services not covered by the resources described on this web site.