-
-
Notifications
You must be signed in to change notification settings - Fork 31
Why not Logtalk?
Logtalk materializes a number of design choices that may not be ideal for some Prolog programming scenarios.
Starting a Logtalk application requires loading both the chosen backend Prolog system and the Logtalk compiler and runtime. This necessarily increases the time it takes to start an application. This may be an issue where very fast startup times are required (of course, this is only meaningful if the applications themselves are small compared with the size of the Logtalk compiler and runtime). Note, however, that the Logtalk compiler and runtime can be precompiled by some Prolog systems for faster loading thus minimizing startup time (e.g. SWI-Prolog supports a Quick Load Format, QLF). The same solution when available can be applied to a Logtalk application.
Although Logtalk provides a complete set of developer tools, it only supports selected native Prolog developer tools (see https://github.com/LogtalkDotOrg/logtalk3/wiki/Developer-Tools for details). Complex applications may require using both Logtalk and Prolog tools, demanding that the programmer learns how to be productive with a larger number of tools.
Logtalk applications making heavy use of dynamic binding may require a backend Prolog compiler with good predicate clause indexing for best performance.
Logtalk favors resilience to changes over convenience and thus does not support implicit predicate imports as in the Prolog use_module/1 directive. In objects (and categories), only use_module/2 directives (or its Logtalk equivalent, the uses/2 directive) can be used. The practical consequence is that you need to use a use_module/2 directive for implicitly calling module predicates and a uses/2 directive for implicitly sending messages to objects. I.e. you need to either explicitly list the predicates or use explicit qualification. This can make the code more verbose (but also prevents applications from breaking when new library predicates are implemented).
Note: the adapter files for some Prolog systems are able to convert in the fly use_module/1 directives into use_module/2 directives. This, however, is not recommended for the reasons stated above.
The Logtalk compiler generates temporary Prolog files when compiling and loading source files. By default, these temporary files are automatically deleted. This requires Logtalk to either work from a writable volume or to define the operating-system temporary directory as the scratch directory. As all common operating-systems natively provide a directory for temporary files, this is not considered an actual limitation although it is worth noting characteristic. Note that running embedded Logtalk applications doesn't not require any runtime compilation of the application source files (as embedding is accomplished using precompiled code).