Changeset 35468 in project

04/29/18 11:09:15 (2 years ago)
felix winkelmann

man/5: update modules chapter

1 moved


  • wiki/man/5/Modules

    r35467 r35468  
    55=== Modules
    7 To allow some control over visible bindings and to organize code at
    8 the global level, a simple module system is available. A ''module''
     7To allow control over visible bindings and to organize code in namespaces,
     8a module system is available. A ''module''
    99defines a set of toplevel expressions that are initially evaluated in
    1010an empty syntactical environment. By ''importing'' other modules,
    11 exported value- and macro-bindings are made visible inside the
     11exported value- and syntax-bindings are made visible inside the
    1212environment of the module that imports them.
    1515control flow or delay the execution of the contained toplevel
    1616forms. The body of a module is executed at load-time, when code is
    17 loaded or accessed via the {{uses}} declaration, just like normal
    18 toplevel expressions. Exported macro-definitions are compiled as
     17loaded or imported, just like normal
     18toplevel expressions. Exported syntax-definitions are compiled as
    1919well, and can be accessed in interpreted or compiled code by loading
    2020and importing the compiled file that contains the module.
    22 Imported toplevel bindings can be assigned (with {{set!}}), any modifications
     22Imported toplevel bindings are mutable and can be assigned
     23(with {{set!}}), any modifications
    2324to these will change the global value and will be visible to other
    2425modules that export or import the same toplevel binding.
    3334* Separation of compile/expansion-time and run-time code is provided, which allows cross compilation
    34 * Module-generating code is only created, when needed
    3535* Supports batch-compilation of separate compilation units
    36 * No separate "identifier" type is used, all identifiers appearing in code and processed in expansions are symbols
     36* Imports can be lexically scoped
    3737* Parameterized modules are supported
    6262{{(IDENTIFIER1 ...)}} or {{(syntax: IDENTIFIER1 ...)}} exports
    6363{{IDENTIFIER1}} (which should name a macro) and also arranges for the
    64 remaining identifiers in the list to be visible in the expansion of
     64remaining identifiers in the list to be visible as value bindings in the expansion of
    6565the macro (this is a hint to the module expander to export bindings
    6666referenced by syntax-definitions which make use of them, but which
    8989mutually recursive modules are not supported.
    91 When compiled, the module information, including exported macros
     91When compiled, the module information, including exported syntax
    9292is stored in the generated binary and available when loading
    9393it into interpreted or compiled code. Note that this is different
    94 to normal macros (outside of module declarations), which are normally
     94to normal syntax (outside of module declarations), which are normally
    9595not exported from compiled code.
    132132An {{IMPORT}} defines a set of bindings that are to be made visible
    133133in the current scope.
    135 Note that the imported bindings are only visible in the next toplevel
    136 expression (regardless of whether the import appears inside or outside
    137 a module):
    139   (begin
    140     (import m1)
    141     ...)              ; imports not visible here
    143   ...                ; imports visible here
    145135===== only
    227217load an import library for a currently unknown module, if the import-
    228218library is either in the extension repository or the current include
    229 path. Import libraries may also be explicitly loaded into the
    230 compiler by using the {{-extend}} compiler option. Interpreted code
     219path. Interpreted code
    231220can simply load the import library to make the module-definition
    232 available. Macro-support definitions defined with {{define-for-syntax}}
     221available. Syntax-support definitions defined with {{define-for-syntax}}
    233222and expansion-time expressions of the form {{(begin-for-syntax ...)}}
    234223will be added to import libraries to make them available for exported
    235 macros. Note that these definitions will ruthlessly pollute the
     224syntax. Note that these definitions will ruthlessly pollute the
    236225toplevel namespace and so they should be used sparingly.
    241230Import libraries for the following modules are initially
    242 available:
     231available outside of a module:
    244233 [module] scheme
    245  [module] r4rs
    246  [module] r5rs
    248 Exports the definitions given in R4RS or R5RS. {{r5rs}} is an alias
    249 for {{scheme}}.
    251  [module] chicken
    253 Everything from the {{library}}, {{eval}} and {{expand}} library units.
    255  [module] extras
    256  [module] data-structures
    257  [module] ports
    258  [module] lolevel
    259  [module] posix
    260  [module] regex
    261  [module] srfi-4
    262  [module] tcp
    264 Modules exporting the bindings from the respective library units.
    266  [module] foreign
    268 Exports all macros and procedures that are used to access foreign
    269 C/C++ code.
     234 [module] (chicken base)
     235 [module] (chicken syntax)
     237Every other module needs to be imported explicitly to have access to
     238its exported identifiers.
Note: See TracChangeset for help on using the changeset viewer.