300 likes | 319 Views
Learn about Lexical and Dynamic Environments in Common Lisp, major design goals, problems, and solutions for better access and representation. Explore environment objects, associated variables, and levels of portability.
E N D
Making Environments Accessible in Common Lisp By Duane Rettig June, 2005
What is An Environment? • A set of bindings of names to values • A context within which to work • Parameterizations of behaviors
Need for Lexical Environments (defun foo (x y z) (flet ((bar (x) (1+ x)) (bas (y) (+ x y))) (+ x (bar y) (baz z))))
Need for Lexical Environments (let ((x (foo))) ... (let ((x (bar))) ... ) ... )
Need for Dynamic Environments ;; In lisp: (defmacro foo (x) `(car ,x)) ;; In a file: (defmacro foo (y) `(1+ ,y)) (defun bar (x) (isqrt (foo x)))
Typical Implementation of Environments (let ((x 10)) ... (symbol-macrolet ((x 'foo)) ... (let ((x 20)) ... ;; here: ))) %venv% <= (... (x . 20) ... (x #.*sm-marker* . foo) ... (x . 10) ...)
Problems with list-style Environments • Environment has no identity • Multiple lists are necessary • Objects not distinguishable as environments • Accesses can be long for deep contour nesting • Persistence and contour structure not automatic
Desired Representation of Lexical Environment Elements Old: x x x Search direction Hash: New: Contours: Search direction (lexical 20) x (symbol-macro foo) (lexical 10)
Environments Access Design Goals (part 1) • Compatible with Common Lisp Spec where possible • Open Source • Start with CLtL2 definition, moving away only when necessary • Move the Language forward • Allow the compiler to be more transparent • Allow portability of optimizations
Environments Access Design Goals (part 2) • Fast (building, access) • Portable (on several levels) • Controllable Persistence • describes the contour forms • easy to conceptualize the program structure • allow multiple entry and annotation for multiple compiler passes and for debuggers • Consistent for compilation and interpretation
Major Departures from Environments in CLtL2 • Entries are bindings, not just names • Environments have “kinds” • Dynamic environment component is added • Augment-environment can reuse object • Declarations are done differently • Define-declaration has different syntax • Declarations sometimes added after variable bindings
Pictorial View of Environment Objects e8 lexical namespaces base 1 3 e7 1 1 1 e6 2 1 e5 1 1 e4 3 e3 2 e2 1 Dynamic namespaces e1 nil
Environment Kinds • Interpreter (for lisps with interpreter) • Compilation (compilation-walking in 7.0) • Evaluation • Compiler (compilation in 7.0) • Macros-only
Variables Associated with Environments • *interpreter-environment* • *compilation-unit-environment* • [*compile-file-environment* in Allegro CL 7.0] • *evaluation-environment*
*interpreter-environment* Usage • Only available when an interpreter exists • Hard to capture - REPL continuously binds
*compilation-unit-environment* Usage • Created when new compile-file or with-compilation-unit established • Can be built with either • sys:make-compilation-unit-environment or • sys:make-compile-file-environment (deprecated)
*evaluation-environment* Usage • Read-only feel - definitions taken from environment but stored globally
Extensions Beyond the Spec • Compiler environments • Extra arg to macroexpand/macroexpand-1 for special operators • Environments extend to compilation-unit
To Do: • “Split” define-declaration to allow redefinitions and development • Add expression-information and :expression argument to augment-environment • Encourage CL vendors to make use of this module • Accept suggestions
Levels of Portability/Porting • Level 0: • Level 1: • Level 2: • Level 3: • Level 4:
Levels of Portability/Porting • Level 0: • Implementation has its own proprietary (open or not) representation • Level 1: • Level 2: • Level 3: • Level 4:
Levels of Portability/Porting • Level 0: Proprietary • Level 1: • Compilation and operation of the basic functionality • Level 2: • Level 3: • Level 4:
Levels of Portability/Porting • Level 0: Proprietary • Level 1: Basic • Level 2: • Current environment emulated at the Environments Access interface level • Level 3: • Level 4:
Levels of Portability/Porting • Level 0: Proprietary • Level 1: Basic • Level 2: Emulation • Level 3: • Environments Access holds the information, Proprietary interface queries it • Level 4:
Levels of Portability/Porting • Level 0: Proprietary • Level 1: Basic • Level 2: Emulation • Level 3: Transitional • Level 4: • Environments Access fully integrated into compiler, optionally interpreter • proprietary representation unused or deprecated
Levels of Portability/Porting • Level 0: Proprietary • Level 1: Basic • Level 2: Emulation • Level 3: Transitional • Level 4: Full
Current Links • http://franz.com/support/documentation/7.0/doc/environments.htm • (http://www.lispwire.com/entry-proganal-envaccess-des)
Look at the Implementation (switch to Linux) • Bring up lisps and demonstrate Environment building/access • Look at source code for major functions