paul@253 | 1 | Native Function Definitions
|
paul@253 | 2 | ===========================
|
paul@253 | 3 |
|
paul@253 | 4 | Native functions are principally associated with the facilities of the
|
paul@773 | 5 | builtins and native modules. Although Python modules are provided to define
|
paul@773 | 6 | the contents of these modules (the former referenced via the __builtins__
|
paul@773 | 7 | module name in programs), unlike other modules, it is not generally desirable
|
paul@773 | 8 | to translate the code of such modules literally. Instead, native functions are
|
paul@773 | 9 | provided which define the functionality, and these functions will be provided
|
paul@773 | 10 | by the eventual platform-specific implementation.
|
paul@253 | 11 |
|
paul@253 | 12 | However, some definitions found in the builtins module should be translated,
|
paul@253 | 13 | since it is possible to define the behaviour of these objects efficiently in
|
paul@253 | 14 | Python. Such definitions employ docstrings, indicating that the contents of
|
paul@773 | 15 | the object definitions are to be traversed by the code generator. Other
|
paul@773 | 16 | library modules can also be translated.
|
paul@773 | 17 |
|
paul@773 | 18 | In addition to module functionality, some features of generated programs will
|
paul@773 | 19 | also be defined in terms of native code. The intention is to implement such
|
paul@773 | 20 | code in syspython (see syspython.txt), where the semantics of the language can
|
paul@773 | 21 | unambiguously and explicitly support the low-level operations required. In
|
paul@773 | 22 | other words, since syspython does not need to support the breadth of Python
|
paul@773 | 23 | semantics, certain elements of the syntax can be repurposed for low-level
|
paul@773 | 24 | operations without conflicting with the expression of conventional program
|
paul@773 | 25 | semantics (which will have been rewritten in other terms in the translation
|
paul@773 | 26 | process).
|