..
   This file is part of Logtalk <https://logtalk.org/>
   SPDX-FileCopyrightText: 1998-2026 Paulo Moura <pmoura@logtalk.org>
   SPDX-License-Identifier: Apache-2.0

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.


.. _categories_categories:

Categories
==========

Categories are *fine-grained units of code reuse* and can be regarded as a
dual concept of protocols. Categories provide a way to encapsulate a set
of related predicate declarations and definitions that do not represent
a complete object and that only make sense when composed with other
predicates. Categories may also be used to break a complex object into
functional units. A category can be imported by several objects (without
code duplication), including objects participating in prototype or
class-based hierarchies. This concept of categories shares some ideas
with Smalltalk-80 functional categories [Goldberg83]_, Flavors mix-ins
[Moon86]_ (without necessarily implying multi-inheritance), and
Objective-C categories [Cox86]_. Categories may also *complement*
existing objects, thus providing a :term:`hot patching` mechanism
inspired by the Objective-C categories functionality.

Logtalk defines a built-in category, :ref:`core_messages <apis:core_messages/0>`,
which is described at the end of this section.

.. _categories_defining:

Defining a new category
-----------------------

We can define a new category in the same way we write Prolog code: by
using a text editor. Logtalk source files may contain one or more
objects, categories, or protocols. If you prefer to define each entity
in its own source file, it is recommended that the file be named after
the category. By default, all Logtalk source files use the extension
``.lgt`` but this is optional and can be set in the adapter files.
Intermediate Prolog source files (generated by the Logtalk compiler)
have, by default, a ``_lgt`` suffix and a ``.pl`` extension. Again, this
can be set to match the needs of a particular Prolog compiler in the
corresponding adapter file. For example, we may define a category named
``documenting`` and save it in a ``documenting.lgt`` source file that
will be compiled to a ``documenting_lgt.pl`` Prolog file (depending on
the :term:`backend compiler <backend Prolog compiler>`, the names of the
intermediate Prolog files may include a directory hash and a process
identifier to prevent file name clashes when embedding Logtalk
applications or running parallel Logtalk processes).

Category names can be atoms or compound terms (when defining parametric
categories). Objects, categories, and protocols share the same name
space: we cannot have a category with the same name as an object or a
protocol.

Category code (directives and predicates) is textually encapsulated by
using two Logtalk directives: :ref:`directives_category_1_4` and
:ref:`directives_end_category_0`. The
most simple category will be one that is self-contained, not depending
on any other Logtalk entity:

::

   :- category(Category).
       ...
   :- end_category.

If a category implements one or more protocols, then the opening
directive will be:

::

   :- category(Category,
       implements([Protocol1, Protocol2, ...])).
       ...
   :- end_category.

A category may be defined as a composition of other categories by
writing:

::

   :- category(Category,
       extends([Category1, Category2, ...])).
       ...
   :- end_category.

This feature should only be used when extending a category without
breaking its functional cohesion (for example, when a modified version
of a category is needed for importing on several unrelated objects). The
preferred way of composing several categories is by importing them into
an object. When a category overrides a predicate defined in an extended
category, the overridden definition can still be called by using the
:ref:`control_call_super_1` control construct.

Categories cannot inherit from objects. In addition, categories cannot
define clauses for dynamic predicates. This restriction applies because
a category can be imported by several objects and because we cannot use
the database handling built-in methods with categories (messages can
only be sent to objects). A consequence of this restriction is that a
category cannot declare a predicate (or non-terminal) as both multifile
and dynamic. However, categories may contain declarations for dynamic
predicates, and they can contain predicates that handle dynamic predicates.
For example:

::

   :- category(attributes).

       :- public(attribute/2).
       :- public(set_attribute/2).
       :- public(del_attribute/2).

       :- private(attribute_/2).
       :- dynamic(attribute_/2).

       attribute(Attribute, Value) :-
           % called in the context of "self"
           ::attribute_(Attribute, Value).

       set_attribute(Attribute, Value) :-
           % retract old clauses in "self"
           ::retractall(attribute_(Attribute, _)),
           % assert new clause in "self"
           ::assertz(attribute_(Attribute, Value)).

       del_attribute(Attribute, Value) :-
           % retract clause in "self"
           ::retract(attribute_(Attribute, Value)).

   :- end_category.

Each object importing this category will have its own ``attribute_/2``
private and dynamic predicate. The predicates ``attribute/2``,
``set_attribute/2``, and ``del_attribute/2`` always access and modify
the dynamic predicate contained in the object receiving the
corresponding messages (i.e., *self*). But it's also possible to define
predicates that handle dynamic predicates in the context of *this*
instead of *self*. For example:

::

   :- category(attributes).

       :- public(attribute/2).
       :- public(set_attribute/2).
       :- public(del_attribute/2).

       :- private(attribute_/2).
       :- dynamic(attribute_/2).

       attribute(Attribute, Value) :-
           % call in the context of "this"
           attribute_(Attribute, Value).

       set_attribute(Attribute, Value) :-
           % retract old clauses in "this"
           retractall(attribute_(Attribute, _)),
           % asserts clause in "this"
           assertz(attribute_(Attribute, Value)).

       del_attribute(Attribute, Value) :-
           % retract clause in "this"
           retract(attribute_(Attribute, Value)).

   :- end_category.

When defining a category that declares and handles dynamic predicates,
working in the context of *this* ties those dynamic predicates to the
object importing the category, while working in the context of *self*
allows each object inheriting from the object that imports the category
to have its own set of clauses for those dynamic predicates.

.. _categories_patching:

Hot patching
------------

A category may also explicitly complement one or more existing objects,
thus providing :term:`hot patching` functionality inspired by Objective-C
categories:

::

   :- category(Category,
       complements([Object1, Object2, ....])).
       ...
   :- end_category.

This allows us to add missing directives (e.g., to define
:term:`aliases <predicate alias>` for complemented object predicates),
replace broken predicate definitions, add new predicates, and add protocols
and categories to existing objects without requiring access or modifications
to their source code. Common scenarios are adding logging or debugging
predicates to a set of objects. Complemented objects need to be compiled
with the :ref:`complements <flag_complements>` compiler flag set ``allow``
(to allow both patching and adding functionality) or ``restrict`` (to allow
only adding new functionality). A complementing category takes preference
over a previously loaded complementing category for the same object, thus
allowing patching a previous patch if necessary.

When replacing a predicate definition, it is possible to call the overridden
definition in the object from the new definition in the category by using the
:ref:`call_in_this_1` control construct. This construct is only meaningful
when used within categories and requires a compile-time bound goal argument,
which is called in :term:`this` (i.e., in the context of the complemented
object or the object importing a category). As an example, consider the
following object:

::

   :- object(bird).

       :- set_logtalk_flag(complements, allow).

       :- public(make_sound/0).
       make_sound :-
           write('Chirp, chirp!'), nl.

   :- end_object.

We can use the ``(@)/1`` control construct to wrap the original ``make_sound/0``
predicate definition by writing:

::

   :- category(logging,
       complements(bird)).

       make_sound :-
           write('Started making sound...'), nl,
           @make_sound,
           write('... finished making sound.'), nl.

   :- end_category.

After loading the object and the category, calling the ``make_sound/0``
predicate will result in the following output:

.. code-block:: text

   | ?- bird::make_sound.

   Started making sound...
   Chirp, chirp!
   ... finished making sound.
   yes

Note that :term:`super calls <super call>` from predicates defined in
complementing categories lookup inherited definitions as if the calls
were made from the complemented object instead of the category ancestors.
This allows more comprehensive object patching. But it also means that,
if you want to patch an object so that it imports a category that extends
another category and uses super calls to access the extended category
predicates, you will need to define a (possibly empty) complementing
category that extends the category that you want to add.

An unfortunate consequence of allowing an object to be patched at
runtime using a complementing category is that it disables the use of
:term:`static binding` optimizations for messages sent to the complemented
object, as it can always be later patched, thus rendering the static
binding optimizations invalid.

Another important caveat is that, while a complementing category can
replace a predicate definition, local callers of the replaced predicate
will still call the non-patched version of the predicate. This is a
consequence of the lack of a portable solution at the
:term:`backend Prolog compiler` level for replacing static predicate
definitions.

.. _categories_finding:

Finding defined categories
--------------------------

We can find, by backtracking, all defined categories by using the
:ref:`predicates_current_category_1` built-in predicate with an
unbound argument:

.. code-block:: text

   | ?- current_category(Category).

This predicate can also be used to test if a category is defined by
calling it with a valid category identifier (an atom or a compound
term).

.. _categories_creating:

Creating a new category at runtime
----------------------------------

A category can be dynamically created at runtime by using the
:ref:`predicates_create_category_4` built-in predicate:

.. code-block:: text

   | ?- create_category(Category, Relations, Directives, Clauses).

The first argument should be either a variable or the name of the new
category (a Prolog atom, which must not match with an existing entity
name). The remaining three arguments correspond to the relations
described in the opening category directive and to the category code
contents (directives and clauses).

For example, the call:

.. code-block:: text

   | ?- create_category(
            ccc,
            [implements(ppp)],
            [private(bar/1)],
            [(foo(X):-bar(X)), bar(1), bar(2)]
        ).

is equivalent to compiling and loading the category:

::

   :- category(ccc,
       implements(ppp)).

       :- dynamic.

       :- private(bar/1).

       foo(X) :-
           bar(X).

       bar(1).
       bar(2).

   :- end_category.

If we need to create a lot of (dynamic) categories at runtime, then it
is best to define a metaclass or a prototype with a predicate that will
call this built-in predicate in order to provide more sophisticated
behavior.

.. _categories_abolishing:

Abolishing an existing category
-------------------------------

Dynamic categories can be abolished using the
:ref:`predicates_abolish_category_1` built-in predicate:

.. code-block:: text

   | ?- abolish_category(Category).

The argument must be an identifier of a defined dynamic category;
otherwise, an error will be thrown.

.. _categories_directives:

Category directives
-------------------

Category directives are used to define category properties, document
category dependencies on other Logtalk entities, and load the
contents of files into a category.

.. _categories_dynamic:

Dynamic categories
~~~~~~~~~~~~~~~~~~

As usually happens with Prolog code, a category can be either static or
dynamic. A category created during the execution of a program is always
dynamic. A category defined in a file can be either dynamic or static.
Dynamic categories are declared by using the :ref:`directives_dynamic_0`
directive in the category source code:

::

   :- dynamic.

The directive must precede any predicate directives or clauses. Please
be aware that using dynamic code results in a performance hit when
compared to static code. We should only use dynamic categories when
these need to be abolished during program execution.

.. _categories_documentation:

Category documentation
~~~~~~~~~~~~~~~~~~~~~~

A category can be documented with arbitrary user-defined information
by using the :ref:`directives_info_1` entity directive. See the
:ref:`documenting_documenting` section for details.

.. _categories_include:

Loading files into a category
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The :ref:`directives_include_1` directive
can be used to load the contents of a file into a category. See the
:ref:`objects_objects` section for an example of using this
directive.

.. _categories_object_aliases:

Declaring object aliases
~~~~~~~~~~~~~~~~~~~~~~~~

The :ref:`directives_uses_1` directive can be used to declare object aliases.
The typical uses of this directive are to shorten long object names and to
simplify experimenting with different object implementations of the same
protocol when using explicit message-sending.

.. _categories_relationships:

Category relationships
----------------------

Logtalk provides two sets of built-in predicates that enable us to query
the system about the relationships that a category has with other entities.

The built-in predicates :ref:`predicates_implements_protocol_2_3`
and :ref:`predicates_conforms_to_protocol_2_3`
allow us to find which categories implement which protocols:

.. code-block:: text

   | ?- implements_protocol(Category, Protocol, Scope).

or, if we also want to consider inherited protocols:

.. code-block:: text

   | ?- conforms_to_protocol(Category, Protocol, Scope).

Note that, if we use an unbound first argument, we will need to use the
:ref:`predicates_current_category_1` built-in predicate to ensure that
the returned entity is a category and not an object.

To find which objects import which categories, we can use the
:ref:`predicates_imports_category_2_3` built-in predicates:

.. code-block:: text

   | ?- imports_category(Object, Category).

or, if we also want to know the importation scope:

.. code-block:: text

   | ?- imports_category(Object, Category, Scope).

Note that a category may be imported by several objects.

To find which categories extend other categories, we can use the
:ref:`predicates_extends_category_2_3` built-in predicates:

.. code-block:: text

   | ?- extends_category(Category1, Category2).

or, if we also want to know the extension scope:

.. code-block:: text

   | ?- extends_category(Category1, Category2, Scope).

Note that a category may be extended by several categories.

To find which categories explicitly complement existing objects we can
use the :ref:`predicates_complements_object_2` built-in predicate:

.. code-block:: text

   | ?- complements_object(Category, Object).

Note that a category may explicitly complement several objects.

.. _categories_properties:

Category properties
-------------------

We can find the properties of defined categories by calling the built-in
predicate :ref:`predicates_category_property_2`:

.. code-block:: text

   | ?- category_property(Category, Property).

The following category properties are supported:

``static``
   The category is static
``dynamic``
   The category is dynamic (and thus can be abolished in runtime by
   calling the :ref:`predicates_abolish_category_1` built-in predicate)
``built_in``
   The category is a built-in category (and thus always available)
``file(Path)``
   Absolute path of the source file defining the category (if
   applicable)
``file(Basename, Directory)``
   Basename and directory of the source file defining the category (if
   applicable); ``Directory`` always ends with a ``/``
``lines(BeginLine, EndLine)``
   Source file begin and end lines of the category definition (if
   applicable)
``directive(BeginLine, EndLine)``
   Source file begin and end lines of the category opening directive (if
   applicable)
``events``
   Messages sent from the category generate events
``source_data``
   Source data available for the category
``info(List)``
   List of the compound term representation of the object ``info/1`` pairs with the key as functor.
``public(Resources)``
   List of public predicates and operators declared by the category
``protected(Resources)``
   List of protected predicates and operators declared by the category
``private(Resources)``
   List of private predicates and operators declared by the category
``declares(Predicate, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for a predicate declared by the category
``defines(Predicate, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for a predicate defined by the category
``includes(Predicate, Entity, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for an object multifile predicate that are defined
   in the specified entity (the properties include
   ``number_of_clauses(Number)``, ``number_of_rules(Number)``,
   ``lines(Start,End)``, and ``line_count(Start)`` with ``Start-End`` being the line range of the
   first multifile predicate clause)
``provides(Predicate, Entity, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for other entity multifile predicate that are
   defined in the category (the properties include
   ``number_of_clauses(Number)``, ``number_of_rules(Number)``,
   ``lines(Start,End)``, and ``line_count(Start)`` with ``Start-End`` being the line range of the
   first multifile predicate clause)
``references(Reference, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for other references to entities in calls to the
   execution-context built-in methods and in directives for multifile predicates and multifile non-terminals
   that are found in the category (the properties include ``in(Context)``, ``non_terminal(NonTerminal)``,
   ``include(File)``, ``lines(Start,End)``, and ``line_count(Start)`` with ``Start-End`` being the line range of
   the first reference, a directive, a predicate clause, or a non-terminal grammar rule; the possible values for
   ``Context`` are ``multifile``, ``dynamic``, ``discontiguous``, ``meta_predicate``, ``meta_non_terminal``,
   and ``clause``); ``Reference`` can be either ``Entity`` or ``Entity::Functor/Arity``
``alias(Entity, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for an :term:`entity alias` declared by the object
   (the properties include ``object`` in case of an object alias, ``module`` in case of a module alias,
   ``for(Original)``, ``lines(Start,End)``, and ``line_count(Start)`` with ``Start-End`` being the line range
   of the ``uses/1`` or ``use_module/1`` directive)
``alias(Predicate, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for a :term:`predicate alias` declared by the category
   (the properties include ``predicate``, ``for(Original)``, ``from(Entity)``, ``non_terminal(NonTerminal)``,
   ``lines(Start,End)``, and ``line_count(Start)`` with ``Start-End`` being the line range of the alias directive)
``calls(Call, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for predicate calls made by the category (``Call``
   is either a predicate indicator or a control construct such as
   ``(::)/1-2`` or ``(^^)/1`` with a predicate indicator as argument; note
   that ``Call`` may not be ground in case of a call to a control
   construct where its argument is only know at runtime; the properties
   include ``caller(Caller)``, ``alias(Alias)``, ``non_terminal(NonTerminal)``,
   ``lines(Start,End)``, and ``line_count(Start)`` with ``Caller``, ``Alias``, and ``NonTerminal``
   being predicate indicators and ``Start-End`` being the line range of the
   predicate clause or directive making the call)
``updates(Predicate, Properties)``
   List of :ref:`properties <grammar_entity_properties>` for dynamic predicate updates (and also access
   using the ``clause/2`` predicate) made by the object (``Predicate``
   is either a predicate indicator or a control construct such as
   ``(::)/1-2`` or ``(:)/2`` with a predicate indicator as argument; note
   that ``Predicate`` may not be ground in case of a control construct
   argument only know at runtime; the properties include
   ``updater(Updater)``, ``alias(Alias)``, ``non_terminal(NonTerminal)``,
   ``lines(Start,End)``, and ``line_count(Start)`` with ``Updater`` being a (possibly multifile)
   predicate indicator, ``Alias`` and ``NonTerminal`` being predicate
   indicators, and ``Start-End`` being the line range of the predicate clause
   or directive updating the predicate)
``number_of_clauses(Number)``
   Total number of predicate clauses defined in the category (includes
   both user-defined clauses and auxiliary clauses generated by the
   compiler or by the :ref:`expansion hooks <expansion_expansion>` but
   does not include clauses for multifile predicates defined for other
   entities or clauses for the category own multifile predicates
   contributed by other entities)
``number_of_rules(Number)``
   Total number of predicate rules defined in the category (includes
   both user-defined rules and auxiliary rules generated by the compiler
   or by the :ref:`expansion hooks <expansion_expansion>` but does not
   include rules for multifile predicates defined for other entities or
   rules for the category own multifile predicates contributed by other
   entities)
``number_of_user_clauses(Number)``
   Total number of user-defined predicate clauses defined in the
   category (does not include clauses for multifile predicates defined
   for other entities or clauses for the category own multifile predicates
   contributed by other entities)
``number_of_user_rules(Number)``
   Total number of user-defined predicate rules defined in the category
   (does not include rules for multifile predicates defined for other
   entities or rules for the category own multifile predicates contributed
   by other entities)

Some properties, such as line numbers, are only available when the category is
defined in a source file compiled with the :ref:`source_data <flag_source_data>`
flag turned on. Moreover, line numbers are only supported in
:term:`backend Prolog compilers <backend Prolog compiler>`
that provide access to the start line of a read term. When such support is
not available, the value ``-1`` is returned for the start and end lines.

The properties that return the number of clauses (rules) report the
clauses (rules) *textually defined in the object* for both multifile and
non-multifile predicates. Thus, these numbers exclude clauses (rules)
for multifile predicates *contributed* by other entities.

.. _categories_importing:

Importing categories
--------------------

Any number of objects can import a category. In addition, an object may
import any number of categories. The syntax is very simple:

::

   :- object(Object,
       imports([Category1, Category2, ...])).
       ...
   :- end_object.

To make all public predicates imported via a category protected, or to
make all public and protected predicates private, we prefix the
category's name with the corresponding keyword:

::

   :- object(Object,
       imports(private::Category)).
       ...
   :- end_object.

or:

::

   :- object(Object,
       imports(protected::Category)).
       ...
   :- end_object.

Omitting the scope keyword is equivalent to writing:

::

   :- object(Object,
       imports(public::Category)).
       ...
   :- end_object.

.. _categories_predicates:

Calling category predicates
---------------------------

Category predicates can be called from within an object by sending a
message to *self* or using a *super* call. Consider the following
category:

::

   :- category(output).

       :- public(out/1).

       out(X) :-
           write(X), nl.

   :- end_category.

The predicate ``out/1`` can be called from within an object importing
the category by simply sending a message to *self*. For example:

::

   :- object(worker,
       imports(output)).

       ...
       do(Task) :-
           execute(Task, Result),
           ::out(Result).
       ...

   :- end_object.

This is the recommended way of calling a category predicate that can be
specialized/overridden in a descendant object, as the predicate definition
lookup will start from *self*.

A direct call to a predicate definition found in an imported category can
be made using the :ref:`control_call_super_1`
control construct. For example:

::

   :- object(worker,
       imports(output)).

       ...
       do(Task) :-
           execute(Task, Result),
           ^^out(Result).
       ...

   :- end_object.

This alternative should only be used when the user knows a priori that
the category predicates will not be specialized or redefined by
descendant objects of the object importing the category. Its advantage
is that, when the :ref:`optimize <flag_optimize>` flag is turned
on, the Logtalk compiler will try to optimize the calls by using
:term:`static binding`. When :term:`dynamic binding` is used due to e.g.
the lack of sufficient information at compilation time, the performance is
similar to calling the category predicate using a message to :term:`self`
(in both cases, a predicate lookup caching mechanism is used).

.. _categories_parametric:

Parametric categories
---------------------

Category predicates can be parameterized in the same way as object predicates
by using a compound term as the category identifier where all the arguments of
the compound term are variables. These variables, the *category parameters*,
are *logical variables* and can be accessed by calling the :ref:`methods_parameter_2`
or :ref:`methods_this_1` built-in local methods in the category predicate
clauses or by using :term:`parameter variables <parameter variable>`.

As a consequence of parameters being logical variables, when defining, for
example, a parametric category named ``foo/1``, ``foo(bar)`` and ``foo(baz)``
are different parameterizations of the same category, not distinct categories.

Category parameter values can be defined by the importing objects.
For example:

::

   :- object(speech(Season, Event),
       imports([dress(Season), speech(Event)])).
       ...
   :- end_object.

Note that access to category parameters is only possible from within the
category. In particular, calls to the :ref:`methods_this_1` built-in local
method from category predicates always access the importing object identifier
(and thus object parameters, not category parameters).

.. _categories_built_in:

Built-in categories
-------------------

Logtalk defines a built-in category that is always available for any
application.

.. _categories_core_messages:

The built-in category ``core_messages``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The built-in :ref:`core_messages <apis:core_messages/0>` category provides
default translations for all compiler and runtime printed messages, such as
warnings and errors. It does not define any public predicates.

Multi-threading applications
----------------------------

When writing multi-threading applications, user-defined predicates calling
built-in predicates such as ``create_category/4`` and ``abolish_category/1``
may need to be declared synchronized in order to avoid race conditions.
