1 / 30

Making Environments Accessible in Common Lisp

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))

aelwen
Download Presentation

Making Environments Accessible in Common Lisp

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Making Environments Accessible in Common Lisp By Duane Rettig June, 2005

  2. What is An Environment? • A set of bindings of names to values • A context within which to work • Parameterizations of behaviors

  3. Need for Lexical Environments (defun foo (x y z) (flet ((bar (x) (1+ x)) (bas (y) (+ x y))) (+ x (bar y) (baz z))))

  4. Need for Lexical Environments (let ((x (foo))) ... (let ((x (bar))) ... ) ... )

  5. 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)))

  6. Typical Implementation of Environments (let ((x 10)) ... (symbol-macrolet ((x 'foo)) ... (let ((x 20)) ... ;; here: ))) %venv% <= (... (x . 20) ... (x #.*sm-marker* . foo) ... (x . 10) ...)

  7. 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

  8. 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)

  9. 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

  10. 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

  11. 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

  12. 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

  13. Environment Kinds • Interpreter (for lisps with interpreter) • Compilation (compilation-walking in 7.0) • Evaluation • Compiler (compilation in 7.0) • Macros-only

  14. Variables Associated with Environments • *interpreter-environment* • *compilation-unit-environment* • [*compile-file-environment* in Allegro CL 7.0] • *evaluation-environment*

  15. *interpreter-environment* Usage • Only available when an interpreter exists • Hard to capture - REPL continuously binds

  16. *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)

  17. *evaluation-environment* Usage • Read-only feel - definitions taken from environment but stored globally

  18. Extensions Beyond the Spec • Compiler environments • Extra arg to macroexpand/macroexpand-1 for special operators • Environments extend to compilation-unit

  19. 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

  20. Levels of Portability/Porting • Level 0: • Level 1: • Level 2: • Level 3: • Level 4:

  21. Levels of Portability/Porting • Level 0: • Implementation has its own proprietary (open or not) representation • Level 1: • Level 2: • Level 3: • Level 4:

  22. Levels of Portability/Porting • Level 0: Proprietary • Level 1: • Compilation and operation of the basic functionality • Level 2: • Level 3: • Level 4:

  23. 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:

  24. 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:

  25. 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

  26. Levels of Portability/Porting • Level 0: Proprietary • Level 1: Basic • Level 2: Emulation • Level 3: Transitional • Level 4: Full

  27. Current Levels of Support

  28. Current Links • http://franz.com/support/documentation/7.0/doc/environments.htm • (http://www.lispwire.com/entry-proganal-envaccess-des)

  29. Look at the Implementation (switch to Linux) • Bring up lisps and demonstrate Environment building/access • Look at source code for major functions

  30. Thank You.

More Related