You can edit this page using wiki syntax for markup.

Article contents:== Outdated egg! This is an egg for CHICKEN 4, the unsupported old release. You're almost certainly looking for [[/eggref/5/static-modules|the CHICKEN 5 version of this egg]], if it exists. If it does not exist, there may be equivalent functionality provided by another egg; have a look at the [[https://wiki.call-cc.org/chicken-projects/egg-index-5.html|egg index]]. Otherwise, please consider porting this egg to the current version of CHICKEN. [[tags: eggs]] [[toc:]] == static-modules === Description {{static-modules}} is a Scheme implementation of the module system described by Xavier Leroy in the paper [[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.4138|A Modular Module System]]. === Library Procedures ==== Identifiers <procedure>(ident? X) -> BOOL</procedure> Returns {{#t}} if {{X}} is an identifier, {{#f}} otherwise. <procedure>(ident-name IDENT) -> STRING</procedure> Returns the string name associated with the given identifier. <procedure>(ident-stamp IDENT) -> INT</procedure> Returns the unique stamp of the given identifier. <procedure>(ident-create NAME) -> IDENT</procedure> Returns a fresh identifier associated with the given name. <procedure>(ident-equal? IDENT IDENT) -> BOOL</procedure> Returns {{#t}} if the stamps of the given identifiers are equal, {{#f}} otherwise. <procedure>(ident-empty) -> IDENV</procedure> Returns an empty identifier environment. <procedure>(ident-add IDENT DATA IDENV) -> IDENV</procedure> Adds the given identifier and associated data to the given identifier environment. <procedure>(ident-find IDENT IDENV) -> DATA</procedure> Looks up the given identifier in the given identifier environment and returns the associated data, or {{#f}} if not found. ==== Access paths We refer to named types, values (variables), and modules either by identifier (if we are in the scope of their binding) or via the dot notation, e.g. {{M.x}} to refer to component {{x}} of module {{M}}. Access paths represent both kinds of references. <procedure>(path? X) -> BOOL</procedure> Returns {{#t}} if {{X}} is an access path, {{#f}} otherwise. <procedure>(Pident IDENT) -> PATH</procedure> Returns a path consisting of the given identifier. <procedure>(Pdot PATH STRING) -> PATH</procedure> Returns an access path for the given path and field. <procedure>(path-equal? PATH PATH) -> BOOL</procedure> Returns {{#t}} if the two given paths are equal, {{#f}} otherwise. ==== Substitutions <procedure>(subst-add IDENT PATH IDENV) -> IDENV</procedure> Extends the substition environment with the given identifier and path. <procedure>(subst-path PATH IDENV) -> PATH</procedure> Applies the given substitutions to the given path. <procedure>(subst-identity) -> IDENV</procedure> Returns an empty substitution environment. ==== Abstract syntax for the base language <procedure>(make-core-syntax term? valtype? deftype? kind? make-valtype make-deftype subst-valtype subst-deftype subst-kind)</procedure> This procedure creates the structure describing base language syntax. The meaning of the fields is as follows: * {{term?}}: predicate for value expressions * {{valtype?}}: predicate for type expressions * {{deftype?}}: predicate for type definitions * {{kind?}}: predicate for the kinds that a type definition can have * {{make-valtype}}: constructor for type expressions * {{make-deftype}}: constructor for type definitions * {{subst-valtype}}: substitution function for type expressions * {{subst-deftype}}: substitution function for type definitions * {{subst-kind}}: substitution function for kinds ==== Abstract syntax for the module language <procedure>(make-mod-syntax core)</procedure> This procedure creates the structure describing module language syntax. {{core}} is an object created by {{make-core-syntax}}. This procedure returns multiple values with the following meaning: * {{modtype?}} {{Signature}} {{Functorty}}: predicate and constructors for module type definitions * {{modspec?}} {{Value_sig}} {{Type_sig}} {{Module_sig}}: predicate and constructors for module type expressions * {{modterm?}} {{Modid}} {{Structure}} {{Functor}} {{Mapply}} {{Constraint}}: module term constructors * {{moddef?}} {{Value_def}} {{Type_def}} {{Module_def}}: predicate and constructor for module definitions * {{subst-modtype}} {{subst-modspec}} {{subst-typedecl}}: substitution procedures ==== Type-checking the base language <procedure>(make-core-typing type-term kind-deftype check-valtype check-kind valtype-match deftype-equiv kind-match deftype-of-path)</procedure> This procedure creates the structure describing base language type checking. The meaning of the fields is as follows: * {{type-term}}: the main typing function, which takes a type and an environment, and returns the principal type of the term in the given environment * {{kind-deftype}}: infers and returns the kind of the given definable type * {{check-valtype}} {{check-kind}}: check the well-formedness of type and kind expressions in the base language * {{valtype-match}} {{deftype-equiv}} {{kind-match}}: checking values vs. signatures * {{deftype-of-path}}: transforms a type path and its kind into the corresponding definable type ==== Type-checking the module language <procedure>(make-mod-typing core-syntax core-typing)</procedure> This procedure creates the structure describing module language type checking. {{core-syntax}} is an object created by {{make-core-syntax}}, and {{core-typing}} is an object created by {{make-core-typing}}. This procedure returns multiple values with the following meaning: * {{check-modtype}}: checks the well-formedness of a module type * {{check-signature}}: checks the well-formedness of a signature * {{type-modterm}}: infers and returns the type of a module term * {{type-moddef}}: infers and returns the type of a module definition (sequence of definitions) * {{type-definition}}: infers and returns the type of a definition (inside a module or at toplevel) ==== Scoping This library implements generic scoping pass for the module language. This pass is not described in the paper. Scoping is the act of associating identifiers with their binding location. We assume that the parser generates fresh identifiers each time it encounters an occurrence of a lexical identifier in the program, and stores those fresh identifiers in the abstract syntax tree it constructs. The scoping pass rewrites the abstract syntax tree to use identical identifiers at a binding site and at all its usage sites. <procedure>st-empty</procedure> Empty scoping table. <procedure>(st-enter-value ID SC) -> SC</procedure> Enters a value identifier in the given scoping table. <procedure>(st-enter-type ID SC) -> SC</procedure> Enters a type identifier in the given scoping table. <procedure>(st-enter-module ID SC) -> SC</procedure> Enters a module identifier in the given scoping table. <procedure>(st-value-path PATH SC) -> PATH</procedure> <procedure>(st-type-path PATH SC) -> PATH</procedure> <procedure>(st-module-path PATH SC) -> PATH</procedure> <procedure>(st-scope-module PATH SC) -> PATH</procedure> ==== Evaluation <procedure>(make-mod-eval core-syntax core-eval enter-val)</procedure> This procedure creates the structure describing module language type checking. {{core-syntax}} is an object created by {{make-core-syntax}}, and {{core-eval}} is a procedure to evalue core syntactic terms. This procedure returns multiple values with the following meaning: * {{modval?}}: predicate for module values * {{Structure_v}}: constructor for a structure of values * {{Mclosure_v}}: constructor for a structure closure * {{path-find-val}}: given a path and value environment, returns the corresponding value, if it exists in the environment * {{find-module-val}}: like {{path-find-val}}, but only for modules * {{mod-eval}}: given an evaluation environment and a list of module definitions, evaluates and returns the corresponding value === Version History * 1.7 Added record printer for moddef datatype * 1.4 Bug fix in evaluation of constraint terms * 1.3 Bug fix in signature checking * 1.2 Changed make-mod-eval interface to be consistent with the rest of the procedures [thanks to Peter Bex] * 1.1 Removed exports of internally-defined modtype data constructors [thanks to Peter Bex] * 1.0 Initial Release === License {{static-modules}} is based on the code and paper by Xavier Leroy (2000): A modular module system. Journal of Functional Programming, 10, pp 269-303 Copyright 2010-2013 Ivan Raikov and the Okinawa Institute of Science and Technology. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. A full copy of the GPL license can be found at <http://www.gnu.org/licenses/>. Description of your changes:

I would like to authenticate

Spam control

What do you get when you multiply 7 by 8?