Mixing Alore and C in modules

Each module available to Alore code is either an Alore module (fully implemented in Alore) or a C module (fully implemented in C using the Alore C API). Mixed Alore and C module implementations are possible by defining two modules, an Alore module and a C module, and by making all the public definitions available in one of the modules, while the other module is an internal module that should not be imported by clients.

Here is a sketch of using circular dependencies to define a module that is effectively a mixed C/Alore module:

• Define module acme in Alore and module _acme in C.
• Module acme imports _acme and vice versa.
• Module acme defines the public interface of the module.
• _acme is purely an implementation detail and is never imported by external code.
• Function and class definitions in _acme can be made available in the public interface module acme like this:

  module acme
  import _acme
  
  -- Alternative 1
  const MyFunc = _acme::MyFunc
  
  -- Alternative 2
  sub MyFunc2()
    _acme::MyFunc2()
  end
  
  -- The const trick cannot be used with classes, since const definitions
  -- cannot be inherited from or used as exception types in except
  -- statements.
  class MyClass is _acme::MyClass
  end
  

• Since _acme imports acme, it can access the public definitions of the acme module.
• Class hierarchies implemented in C require additional public classes in the acme module like this:

  acme::ConcereteClass (public derived class)
      _acme::ConcreteClass (private C derived class)
          acme::AbstractClass (public base class)
              _acme::AbstractClass (private C base class)